DynamoDb BatchGet scalability

You should expect quite consistent latency regardless of table size or item count. That’s part of the core design of DynamoDB.

There are throughout limits, well documented, but within those you see quite steady performance and latency.

Dynamo has the potential to scale to whatever you need it to, but there are several factors you have to consider in order to make sure it will. Thankfully they are easy to master, but without full understanding at table design phase you may run into problems down the road.

Read/write capacity is broken into units called Read Capacity Units (RCU) and Write Capacity Units (WCU). These simply mean how much data you can send per second. The idea is identical for both except 1xRCU is either 2KB or 4KB depending on request type, and 1xWCU is 1KB. In other words, they're priced differently.

So if you have to read 10 items and they are 8KB each, that's 20 RCUs for an eventually consistent read.

The first pitfall is that you provision a table with not enough RCUs. This is not likely to happen as DDB introduced "On demand" tables as the default a few years ago that automatically increase these capacities for you, but you can still configure provisioned tables with as little as 1 RCU, so you need to check what you're using.

Then there is the second limit to capacity; the partitions. Items are stored into 1 or more partitions based on the composite primary key. It's not the key itself but a hash of the key that maps to a particular partition. You don't need to manage anything about the partitions but you do need to make sure the keys you use evenly map your items to as many partitions as the hash function maps to. The partitions are what allows DDB to be so performant but they are limited to 3000 RCUs each. Thankfully DDB will create more of them for you as needed, but again, you need to make sure your primary key spreads your items across partitions evenly. This is achieved by providing high cardinality keys, you should read this full explanation.

Lastly, items in Dynamodb can be upto 400KB in size. Transactional reads cost 1xRCU per 2KB. So a transactional read of a full sized item will cost 200 RCUs. If you chose your partition key poorly and had a hot partition, you max out at (3000/200) = 15 items before DDB would return capacity errors.

In summary, Dynamodb will take care of all the hard work of scaling for you, but if you have bad partition keys, you may one day get a nasty surprise as your number of items grow.