Read and write capacity units in DynamoDB - Deep Dive

Overview - Read and write capacity units

What is it?

Read and write capacity units are measures used in DynamoDB to control how much data you can read or write per second. They help manage the speed and cost of accessing your database. Each unit represents a certain amount of data that can be processed in one second.

Why it matters

Without capacity units, your database could become slow or crash under heavy use, or you might pay too much for unused resources. Capacity units let you balance performance and cost by setting limits that match your application's needs. This keeps your app fast and your bills predictable.

Where it fits

Before learning about capacity units, you should understand basic DynamoDB concepts like tables, items, and attributes. After this, you can learn about auto-scaling, on-demand capacity, and cost optimization strategies.

Mental Model

Core Idea

Read and write capacity units define how much data your DynamoDB table can handle per second, controlling speed and cost.

Think of it like...

Imagine a water pipe where capacity units are the pipe's width. A wider pipe lets more water flow quickly, just like more capacity units let more data flow faster.

┌─────────────────────────────┐
│       DynamoDB Table         │
├─────────────┬───────────────┤
│ Read Units  │ Write Units   │
│ (data/sec)  │ (data/sec)    │
├─────────────┴───────────────┤
│ Controls how much data can   │
│ be read or written per second│
└─────────────────────────────┘

Build-Up - 6 Steps

1

Foundation

What are capacity units?

Concept: Introduces the basic idea of capacity units as limits on data throughput.

DynamoDB uses read capacity units (RCUs) and write capacity units (WCUs) to measure how much data you can read or write per second. One RCU allows you to read up to 4 KB of data per second for eventually consistent reads, and one WCU allows you to write up to 1 KB of data per second.

Result

You understand that capacity units are like tickets that let you read or write a certain amount of data each second.

Understanding capacity units is key to controlling database speed and cost because they set the maximum data flow.

2

Foundation

How capacity units relate to data size

Concept: Explains how data size affects the number of capacity units consumed.

If you read or write an item larger than the unit size (4 KB for reads, 1 KB for writes), DynamoDB uses more capacity units. For example, reading an 8 KB item uses 2 RCUs. This means bigger items cost more capacity.

Result

You see that bigger data means more capacity units are needed, affecting throughput and cost.

Knowing how data size impacts capacity units helps you estimate your needs and avoid surprises.

3

Intermediate

Strongly consistent vs eventually consistent reads

🤔Before reading on: do you think strongly consistent reads use the same capacity units as eventually consistent reads? Commit to your answer.

Concept: Introduces how read consistency affects capacity unit consumption.

Strongly consistent reads use twice the capacity units of eventually consistent reads because they guarantee the latest data. For example, a 4 KB read uses 1 RCU if eventually consistent, but 2 RCUs if strongly consistent.

Result

You learn that choosing read consistency affects how many capacity units you use and thus your throughput and cost.

Understanding this tradeoff helps balance data freshness with performance and cost.

4

Intermediate

Provisioned vs on-demand capacity modes

🤔Before reading on: do you think on-demand mode requires you to set capacity units manually? Commit to your answer.

Concept: Explains the two main ways to manage capacity units in DynamoDB.

Provisioned mode requires you to specify RCUs and WCUs ahead of time, controlling cost and performance. On-demand mode automatically adjusts capacity based on traffic, so you don't set units manually but pay per request.

Result

You understand the difference between manual and automatic capacity management.

Knowing these modes helps you choose the best approach for your app's traffic patterns and budget.

5

Advanced

Auto-scaling capacity units

🤔Before reading on: do you think auto-scaling can prevent throttling completely? Commit to your answer.

Concept: Shows how DynamoDB can adjust capacity units automatically within limits.

Auto-scaling lets DynamoDB increase or decrease your provisioned capacity units based on usage. You set minimum and maximum limits, and DynamoDB adjusts units to handle traffic spikes or drops, helping avoid throttling.

Result

You see how auto-scaling helps maintain performance without manual changes.

Understanding auto-scaling helps you design resilient systems that adapt to changing workloads.

6

Expert

Impact of capacity units on cost and throttling

🤔Before reading on: do you think exceeding capacity units causes data loss? Commit to your answer.

Concept: Explores how capacity units affect billing and request failures.

If your app exceeds provisioned capacity units, DynamoDB throttles requests, causing delays or errors but not data loss. You pay for the capacity units you provision or consume in on-demand mode. Optimizing capacity units balances cost and user experience.

Result

You understand the consequences of mismanaging capacity units and how to avoid throttling.

Knowing the cost-throttling relationship is critical for building efficient, reliable applications.

Under the Hood

DynamoDB tracks the size of each read and write request and calculates how many capacity units it consumes based on item size and read consistency. It enforces limits per table and partition to ensure fair resource use and prevent overload. When limits are reached, requests are throttled. Auto-scaling monitors usage metrics and adjusts provisioned units within set bounds.

Why designed this way?

Capacity units were created to provide predictable performance and cost control in a distributed database. They simplify resource management by abstracting complex hardware limits into easy-to-understand units. Alternatives like unlimited throughput would risk instability or unpredictable costs.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Client     │──────▶│ DynamoDB Table │──────▶│ Capacity Units│
│  Requests   │       │  Processes    │       │  Calculation  │
└───────────────┘       └───────────────┘       └───────────────┘
         │                      │                      │
         │                      │                      ▼
         │                      │               ┌───────────────┐
         │                      │               │ Throughput    │
         │                      │               │ Enforcement   │
         │                      │               └───────────────┘
         │                      │                      │
         │                      │                      ▼
         │                      │               ┌───────────────┐
         │                      │               │ Throttling or │
         │                      │               │ Success       │
         │                      │               └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does one read capacity unit always equal one read request? Commit yes or no.

Common Belief: One read capacity unit equals one read request regardless of item size.

Reality: Read capacity units depend on the size of the item read; larger items consume multiple units.

Why it matters: Assuming one unit per request can cause under-provisioning, leading to throttling and slow app performance.

Quick: Do writes consume the same capacity units as reads? Commit yes or no.

Common Belief: Write capacity units and read capacity units are the same and interchangeable.

Reality: Write capacity units are based on 1 KB per unit, while read capacity units are based on 4 KB per unit and affected by consistency.

Why it matters: Confusing these can cause wrong capacity settings, wasting money or causing throttling.

Quick: Does exceeding capacity units cause data loss? Commit yes or no.

Common Belief: If you exceed capacity units, DynamoDB loses data or corrupts it.

Reality: DynamoDB throttles excess requests but does not lose or corrupt data.

Why it matters: Believing data loss occurs may cause unnecessary panic or over-provisioning.

Quick: Does on-demand mode mean no capacity limits? Commit yes or no.

Common Belief: On-demand capacity mode means unlimited throughput with no limits or throttling.

Reality: On-demand mode scales automatically but still has soft limits and can throttle under extreme traffic.

Why it matters: Thinking on-demand is unlimited can lead to unexpected throttling and downtime.

Expert Zone

1

Capacity units are calculated per partition key, so uneven data distribution can cause throttling even if total capacity seems sufficient.

2

Strongly consistent reads double capacity unit consumption, which can significantly increase costs for read-heavy workloads.

3

Auto-scaling reacts with delay, so sudden traffic spikes can still cause throttling before scaling catches up.

When NOT to use

Provisioned capacity units are not ideal for unpredictable or spiky workloads; on-demand mode or caching layers like DAX are better alternatives. For very large items, consider splitting data or using S3 to reduce capacity unit consumption.

Production Patterns

In production, teams often combine provisioned capacity with auto-scaling and alarms to balance cost and performance. They monitor hot partitions to avoid throttling and use on-demand mode for new or unpredictable apps. Cost optimization includes compressing data to reduce capacity unit use.

Connections

Rate limiting

Capacity units act like rate limits controlling request throughput.

Understanding capacity units as rate limits helps grasp how DynamoDB protects itself from overload and maintains performance.

Cloud cost management

Capacity units directly influence cloud billing and resource allocation.

Knowing capacity units aids in budgeting and optimizing cloud expenses, a key skill in cloud computing.

Traffic shaping in networking

Both use quotas to control data flow and prevent congestion.

Recognizing this similarity helps apply networking concepts to database throughput management.

Common Pitfalls

#1 Underestimating capacity units needed for large items

Wrong approach:

ProvisionedReadCapacityUnits = 5
// Assuming 5 units can read any item

Correct approach:

ProvisionedReadCapacityUnits = 10
// Account for items larger than 4 KB needing multiple units

Root cause:

Misunderstanding that capacity units depend on item size, not just request count.

#2 Using strongly consistent reads without adjusting capacity

Wrong approach:

ReadConsistency = StronglyConsistent
ProvisionedReadCapacityUnits = 5

Correct approach:

ReadConsistency = StronglyConsistent
ProvisionedReadCapacityUnits = 10
// Double units for strong consistency

Root cause:

Ignoring that strong consistency doubles read capacity unit consumption.

#3 Expecting on-demand mode to handle infinite traffic

Wrong approach:

UseOnDemandMode = true
// No limits set or monitored

Correct approach:

UseOnDemandMode = true
SetSoftLimitsAndMonitor = true
// Prepare for throttling under extreme load

Root cause:

Believing on-demand mode is unlimited and requires no monitoring.

Key Takeaways

Read and write capacity units control how much data DynamoDB can process per second, balancing speed and cost.

Capacity units depend on item size and read consistency, so understanding these factors is essential for accurate provisioning.

Choosing between provisioned and on-demand capacity modes affects how you manage throughput and costs.

Auto-scaling helps adjust capacity units automatically but has limits and delays that can cause throttling.

Misunderstanding capacity units leads to throttling, unexpected costs, or poor performance, so careful planning is crucial.