Even the title of this essay is hard to wrap your head around.

But as someone who has built systems on DynamoDB where sub 8ms response times were maintained well past 5T (yes, trillion) records, I can tell you both the title and the concept are worth learning. To do it, you'll need to approach modeling from a different point of view.

Thankfully, there's some excellent resources available. Start with these three.

1. Official DynamoDB Docs

The name is “Best practices for modeling relational data in DynamoDB”, from the AWS docs themselves. Covers a common, recognizable order entry and HR schema, showing the traditional relational model, and then an example of how to reapproach it with an access patterns mindset.

2. Alex Debrie's one-to-many

Through showing strategies for modeling and querying the most common relationship in a relational data model, Alex hits multiple bite-sized samples. Most devs who have used SQL will have the wheels start turning on how to connect this to more complex schemas they've worked with in the past.

3. trek10 Blog Post

Much respect for tackling the Northwind DB as their example. If you've been through a few SQL tutorials, you'll recognize that name. And if you've been reading my earlier DDB posts, the video at the start of the post should look familiar.

These three resources will show you the possibilities of thinking about your relational data models differently.

Still stuck wrapping your head around a concept? Let me know in the comments.

This was the Day 23 #ship30for30 #atomicEssay.

#dynamodb #aws #crosspost

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇

There are a lot of videos and blogs about DynamoDB.

And I've watched/read more than I care to admit. While most hit the basics, they tend to miss out on the advanced, real-world application. And very few give that [Keanu voice] “Woah” moment.

But the #1 must watch video on DynamoDB I've found is Advanced Design Patterns for DynamoDB by Rick Houlihan. (Plenty of Woahs waiting in this one)

Here's a teaser of what it covers:

1. Real, concrete examples of relational data modeled in DDB.
2. Partition Key and Secondary Key deep dives & best practices
3. Examples of mixing different data types in a GSI (Index Overloading design pattern)
4. Access pattern analysis from one of the best in the biz.
5. An example with a dozen access patterns supported by two GSIs on a single table. 🤯 One of the single best aha moments of any DDB resource around.

And so much more ...

Honestly, this video changed my perspective and continues to influence each of my DDB designs. Sometimes you just have to see the examples put to practice to really understand the power. Why not learn it from a master of his craft?

If you are at all interested in DynamoDB, do yourself a favor and clear your calendar to give this a watch.

This was the Day 22 #ship30for30 #atomicEssay.

#crossPost #dynamodb #aws

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇

Choice of persistence stores has an outsized impact on project design.

Having architected many projects for the cloud, I've wrestled with “which persistence” too many times to count. But it is a decision that needs to be made early and thoughtfully.

Applying these 3 questions quickly narrows down the choices.

1. Is the domain model highly normalized and relational?

While most developers will automatically say yes, they're wrong.

In my experience, this is very rare. These designs are usually because of a team's existing relational experience and mental models. Not actually because the domain needs it.

But, if your domain really is highly normalized data, don't think twice. Go relational.

2. Is it cloud native?

If your project isn't already taking advantage of cloud native features, forcing in Dynamo might bring more pain than value. Think traditional web frameworks with built-in ORMs, apps on steady EC2 servers, and similar designs.

On the flip side, if you're already living with fine-grained IAM permissions, async processors off SQS, or highly variable connections (like Lambdas spinning up and down), Dynamo will fit right in.

3. How well do you know the access patterns?

DynamoDB shines when you use access-patterns-first design.

Always start with access patterns. If you don't know them, figure them out. If you can't, because they are truly unknowns, choose a relational DB.

Starting with access patterns will lead to a very different design than data model first.

And often times forcing a decision about the access patterns leads to changes in the application design. That's a good thing.

Notice, I didn't talk about cost, scaling, or high-availability requirements. More often than not, the prior three questions bring an answer before bridging these topics. But if you're still on the fence, those are the next design decisions to make.

Drop a comment if you've struggled with the decision or have different criteria for picking persistence.

This was the Day 21 #ship30for30 #atomicEssay.

#crossPost #dynamodb #aws #serverless

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇