8 DynamoDB bite-sized tips

An architect by trade, practicing architecture in the Cloud. 7x AWS Certified, AWS Community Builder, Serverless advocate, Vue enthusiast.
Search for a command to run...

An architect by trade, practicing architecture in the Cloud. 7x AWS Certified, AWS Community Builder, Serverless advocate, Vue enthusiast.
No comments yet. Be the first to comment.
A clean serverless pattern for streaming real-time AI workflow responses with Server-Sent Events and AWS Lambda

Emails not reaching the inbox due to template Rendering Failure

A secure, efficient, and hassle-free way to run data analytics queries

How to run your AWS Lambda functions with a fixed IP up to 10x cheaper.

Using the API Gateway - SQS integration to create scalable webhook listeners and validate the requests at the API Gateway level

I've been working mainly with relational databases for more than a decade now, but DynamoDB is my database of choice when it comes to serverless apps.
Working with DynamoDB requires a different mindset than working with relational databases.
Here are 8 bite-sized tips:
Spend more time upfront so you won’t regret it later.
Before you design your DynamoDB schema, know the questions it will need to answer, and write down all the access patterns.
Use AWS NoSQL Workbench to model your data.

Maintain as few tables as possible, if modeling relational data, aim for a single-table design.
Use generic attributes for indexes, have fun with index overloading.
If you want to see a real-life example check out my other article on how I'm modeling data for monithor.co.
Also, make sure you watch @alexbdebrie explain single-table design.
Scan operations are less efficient as they always scan the entire table and then filter out values to return the result.
As a table or index grows, the Scan operation slows. Avoid it on large datasets, but if there are no other options use Parallel Scan.
If an item with the same primary key exists in the table, the PutItem operation will replace it.
Use ConditionExpression to avoid overwriting in a single call Instead of doing 2 calls (a GetItem before PutItem).
Distribute items evenly across key Aspace to avoid hot partitions. Do that by expanding the space, add a random number or a calculated suffix to the partition key.
Use parallel scatter-gather queries to retrieve the results.

Group multiple actions together and submit them as a single all-or-nothing operation, if one action fails they’ll all fail.
Don't group unnecessary operations in a transaction, simpler transactions are more likely to succeed.
Leverage the TTL (Time-to-Live) to auto delete items. E.g. auto-remove log data older than X days from a table just by setting the TTL to the desired timestamp.
Just pay attention to the items you set the TTL attribute to.
Yes, you'll read that it can be about 7x more expensive, but unless your DynamoDB bill is $$$ it won’t worth the headache.
Once you know your usage patterns you can switch to Provisioned and fine-tune it.
Watch @houlihan_rick deep-dive videos on DynamoDB advanced design patterns AWS reInvent.
Search YouTube and watch them all from 2017 to date, repetition is the mother of all learning.