NoSQL · Data models beyond tables
How do DynamoDB read and write capacity units work?
Short answer
One WCU covers a 1 KB write per second and one RCU covers a 4 KB strongly consistent read per second, with eventually consistent reads costing half. On-demand mode bills per request instead of provisioned capacity.
Provisioned mode reserves read and write capacity per second and can autoscale. On-demand mode scales automatically and charges per request, which suits spiky or unpredictable traffic but can cost more at steady high volume.
Write: item size 3 KB
WCU per write = ceil(3 / 1) = 3
Read: item size 10 KB, strongly consistent
RCU per read = ceil(10 / 4) = 3
Same read, eventually consistent
RCU per read = ceil(10 / 4) / 2 = 1.5, billed as 2What consumes capacity
- Every read and write, including those that return no data
- Scans consume capacity across the whole table and are usually expensive
- Secondary indexes have their own capacity and write amplification
- Transactions consume roughly twice the capacity because they read and write
- Throttling happens when a partition exceeds its share of capacity
Provisioned capacity is shared across partitions, but each partition has a physical limit. A hot partition can throttle even when the table has unused capacity overall. Adaptive capacity and a better key distribution are the fixes, not just buying more RCUs.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How much does an eventually consistent read cost compared with a strong read?
- 2When would you choose on-demand over provisioned capacity?
- 3Why can a table throttle when overall capacity looks sufficient?
- 4How do transactions affect capacity consumption?
Say it in the interview
Capacity is based on item size and consistency. One write unit covers a one-kilobyte write per second, and one read unit covers a four-kilobyte strongly consistent read, with eventually consistent reads costing half. I round up per request, so a ten-kilobyte read costs three units. Provisioned mode is cheaper at steady load, while on-demand suits spiky traffic. I also watch partition-level throttling, because table-level spare capacity does not help a hot partition.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live NoSQL mock interview and get scored feedback on depth, clarity and confidence.