- Newest
- Most votes
- Most comments
There is indeed a 1000 WCUs/partition limit, but that doesn't mean a table has a 1000 WCUs limit. If your app is well-designed, that is your reads/writes are evenly distributed among partitions, you won't necessarily be constrained by partitions limit. You can't decide how many partitions your table will have, as it's managed internally by dynamodb. It will add more partitions to scale horizontally. But roughly speaking a dynamo partition will store up to 10GB, use 3000 RCUs or 1000 WCUs.
That being said, the more RCUs/WCUs the higher the price. So increasing the provisioned capacity isn't necessarily a valid solution.
A very common pattern to control writes rate is putting an SQS queue in front of dynamodb. So you app publishes write operations to this queue that acts as a buffer of operations. Then you can process messages in that queue using a lambda function. You can control how fast you want to write to dynamodb using lambda's reserve concurrency and SQS batch size.
On the other hand, to compute any data aggregation like likes count, I would recommend you use dynamodb streams and lambda to compute them in a defer way.
As you mention, another alternative would be to use ElastiCache (with Redis flavor) as datastore instead of dynamodb. I don't know your exact requirements but, ElastiCache (or a redis instance in EC2) isn't a serverless solution. Since Redis is a database in memory, you can achieve a higher throughput than with dynamodb, however you would need to figure out how to persist data, so you don't lose it when redis is intentionally/accidentally shut down.
Relevant content
- Accepted Answerasked 2 years ago
- asked 10 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 6 months ago
- AWS OFFICIALUpdated a month ago
- AWS OFFICIALUpdated 2 years ago