Burst capacity in DynamoDB - Deep Dive

Overview - Burst capacity

What is it?

Burst capacity is a feature in DynamoDB that allows your database to handle sudden spikes in traffic by temporarily using extra read or write capacity beyond your provisioned limits. It works by accumulating unused capacity as credits when your traffic is low, which you can then spend during busy times. This helps keep your application responsive without constantly paying for high capacity.

Why it matters

Without burst capacity, your application could slow down or fail when many users access it at once, causing bad user experiences or lost data. Burst capacity lets you handle these spikes smoothly and cost-effectively by using saved-up capacity credits instead of always paying for peak traffic. This means better performance and lower costs.

Where it fits

Before learning burst capacity, you should understand DynamoDB basics like tables, items, and provisioned capacity units. After this, you can explore auto scaling and on-demand capacity modes, which also help manage traffic but in different ways.

Mental Model

Core Idea

Burst capacity is like saving up energy when idle to use extra power during busy moments, letting your database handle sudden traffic spikes smoothly.

Think of it like...

Imagine a water tank that fills slowly when demand is low, storing water. When many people need water quickly, the tank releases the stored water to meet the sudden demand without waiting for the slow refill.

┌─────────────────────────────┐
│       DynamoDB Table        │
├─────────────┬───────────────┤
│ Provisioned │ Burst Credits │
│ Capacity    │ (Saved Units) │
├─────────────┴───────────────┤
│ Normal traffic uses provisioned capacity
│ Low traffic accumulates burst credits
│ High traffic spends burst credits to handle spikes
└─────────────────────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Provisioned Capacity Basics

Concept: Learn what provisioned capacity means in DynamoDB and how it limits read and write operations.

DynamoDB tables have a set amount of read and write capacity units you choose when creating them. These units limit how many reads and writes your table can handle per second. If you exceed these limits, requests may be throttled, causing delays or errors.

Result

You know that provisioned capacity sets a fixed speed limit for your database operations.

Understanding provisioned capacity is essential because burst capacity builds on how unused capacity can be saved and reused.

2

Foundation

What Causes Traffic Spikes in Databases

Concept: Identify common reasons why database traffic suddenly increases and why fixed capacity can struggle.

Traffic spikes happen when many users or processes access your database at once, like during sales, app launches, or batch jobs. Fixed capacity can't always handle these bursts, leading to throttling and slow responses.

Result

You recognize that traffic is not always steady and that databases need ways to handle sudden demand.

Knowing why spikes happen helps you appreciate why burst capacity is necessary to keep apps running smoothly.

3

Intermediate

How Burst Capacity Accumulates Credits

🤔Before reading on: Do you think burst credits accumulate only when traffic is zero or also when traffic is below provisioned capacity? Commit to your answer.

Concept: Burst capacity works by saving unused capacity units as credits when your traffic is below your provisioned limits.

When your database uses less than the provisioned capacity, the unused units become burst credits. These credits accumulate up to a limit and can be spent later to handle traffic above your provisioned capacity temporarily.

Result

You understand that burst credits are like a savings account of unused capacity.

Knowing that credits accumulate during normal or low traffic explains how burst capacity provides flexibility without extra cost.

4

Intermediate

Spending Burst Credits During Traffic Spikes

🤔Before reading on: Do you think burst credits can be used indefinitely or only up to a certain limit? Commit to your answer.

Concept: Burst credits can be spent to temporarily increase your capacity beyond provisioned limits during spikes, but only up to the amount saved.

When traffic exceeds provisioned capacity, DynamoDB uses burst credits to allow extra reads or writes. Once credits run out, requests are throttled until more credits accumulate again.

Result

You see how burst capacity smooths out spikes but is limited by how many credits you have saved.

Understanding the limits of burst credits helps you plan capacity and avoid unexpected throttling.

5

Advanced

Limits and Expiry of Burst Capacity Credits

🤔Before reading on: Do you think burst credits last forever or expire after some time? Commit to your answer.

Concept: Burst credits have a maximum limit and expire if unused for a certain period, so they must be managed carefully.

DynamoDB caps how many burst credits you can save, usually enough for a few minutes of extra capacity. Credits expire after 24 hours if not used, so consistent low traffic is needed to maintain burst capacity.

Result

You learn that burst capacity is a short-term buffer, not a permanent boost.

Knowing credit limits and expiry prevents over-reliance on burst capacity and encourages proper capacity planning.

6

Expert

Burst Capacity Interaction with Auto Scaling and On-Demand

🤔Before reading on: Does burst capacity work the same way with auto scaling and on-demand modes? Commit to your answer.

Concept: Burst capacity is specific to provisioned mode and interacts differently with auto scaling and on-demand capacity modes.

In provisioned mode, burst capacity helps handle short spikes. Auto scaling adjusts provisioned capacity automatically over time but may not react instantly. On-demand mode does not use burst credits but scales instantly with traffic, often at higher cost.

Result

You understand when burst capacity is useful and when other capacity modes might be better.

Knowing how burst capacity fits with other scaling options helps you choose the best strategy for your workload.

Under the Hood

DynamoDB tracks your table's provisioned read and write capacity units and monitors actual usage. When usage is below provisioned capacity, the system credits unused units into a burst credit pool. During traffic spikes, the system draws from this pool to allow extra operations beyond provisioned limits. The credit pool has a maximum size and credits expire after 24 hours if unused. This mechanism runs transparently, balancing performance and cost.

Why designed this way?

Burst capacity was designed to handle real-world traffic patterns where usage fluctuates. Instead of paying for peak capacity all the time, users can save unused capacity as credits to handle bursts. Alternatives like always provisioning high capacity or relying solely on auto scaling were less cost-effective or slower to react. Burst capacity offers a middle ground for predictable but spiky workloads.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│Provisioned    │       │Usage Monitor  │       │Burst Credit   │
│Capacity Units │──────▶│Tracks Usage   │──────▶│Pool (Credits) │
└───────────────┘       └───────────────┘       └───────────────┘
       ▲                        │                      │
       │                        │                      ▼
       │                        │             ┌─────────────────┐
       │                        │             │Traffic Spike    │
       │                        │             │Consumes Credits │
       │                        │             └─────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think burst capacity means unlimited extra capacity during spikes? Commit yes or no.

Common Belief: Burst capacity lets your table handle unlimited traffic spikes without throttling.

Reality: Burst capacity only allows extra capacity up to the amount of saved credits, which is limited and expires if unused.

Why it matters: Assuming unlimited burst capacity can cause unexpected throttling and downtime during heavy traffic.

Quick: Do you think burst capacity works the same in on-demand mode? Commit yes or no.

Common Belief: Burst capacity applies to all DynamoDB capacity modes including on-demand.

Reality: Burst capacity is only for provisioned capacity mode; on-demand mode scales instantly without credits.

Why it matters: Confusing capacity modes can lead to wrong expectations and cost surprises.

Quick: Do you think burst credits accumulate even when traffic is above provisioned capacity? Commit yes or no.

Common Belief: Burst credits accumulate regardless of traffic levels.

Reality: Credits only accumulate when traffic is below provisioned capacity, not during high usage.

Why it matters: Misunderstanding credit accumulation can cause poor capacity planning and throttling.

Quick: Do you think burst credits last forever if unused? Commit yes or no.

Common Belief: Once earned, burst credits never expire.

Reality: Burst credits expire after 24 hours if not used.

Why it matters: Ignoring expiry can lead to overestimating available capacity and unexpected throttling.

Expert Zone

1

Burst capacity credits are tracked separately for read and write units, so one can run out while the other still has credits.

2

The maximum burst credit pool size is proportional to your provisioned capacity, so increasing provisioned units increases burst capacity potential.

3

Burst capacity is most effective for workloads with predictable low usage periods followed by short spikes, not for constantly high or unpredictable traffic.

When NOT to use

Burst capacity is not suitable for workloads with consistently high or unpredictable traffic spikes. In such cases, use on-demand capacity mode for instant scaling or implement auto scaling to adjust provisioned capacity dynamically.

Production Patterns

In production, teams often combine burst capacity with auto scaling to handle short spikes immediately and adjust capacity over time. Monitoring burst credit usage helps avoid throttling. For unpredictable workloads, on-demand mode is preferred despite higher cost.

Connections

Auto Scaling

Builds-on

Understanding burst capacity helps grasp how auto scaling complements it by adjusting provisioned capacity over longer periods, while burst capacity handles short bursts.

Cloud Cost Optimization

Supports

Burst capacity enables cost savings by avoiding over-provisioning, a key principle in cloud cost optimization strategies.

Battery Energy Storage

Similar pattern

Like burst capacity credits, batteries store energy when demand is low and release it during peak usage, showing how resource buffering is a universal concept.

Common Pitfalls

#1 Expecting burst capacity to prevent all throttling during heavy traffic.

Wrong approach:

ProvisionedCapacity = 100
// Assume heavy traffic of 300 units
// Rely only on burst capacity credits to handle 300 units

Correct approach:

ProvisionedCapacity = 100
// Use burst capacity for short spikes
// Implement auto scaling or on-demand mode for sustained high traffic

Root cause:

Misunderstanding burst capacity limits and treating it as unlimited extra capacity.

#2 Confusing capacity modes and expecting burst capacity in on-demand mode.

Wrong approach:

CreateTable with BillingMode = 'PAY_PER_REQUEST'
// Expect burst credits to accumulate and be used

Correct approach:

CreateTable with BillingMode = 'PROVISIONED'
// Use burst capacity credits
// Or use PAY_PER_REQUEST without burst capacity

Root cause:

Not knowing burst capacity applies only to provisioned mode.

#3 Ignoring burst credit expiry and assuming credits accumulate indefinitely.

Wrong approach:

// Accumulate credits over days without usage
// Assume all credits are available during spike

Correct approach:

// Monitor credit usage
// Plan capacity knowing credits expire after 24 hours

Root cause:

Lack of awareness about credit expiration policy.

Key Takeaways

Burst capacity lets DynamoDB temporarily exceed provisioned limits by using saved unused capacity as credits.

Credits accumulate only when usage is below provisioned capacity and expire after 24 hours if unused.

Burst capacity is limited and cannot handle unlimited or sustained traffic spikes.

It applies only to provisioned capacity mode, not on-demand mode.

Combining burst capacity with auto scaling or on-demand mode helps manage varying workloads efficiently and cost-effectively.

Practice

1. What is the main purpose of burst capacity in DynamoDB?

easy

A. To backup data automatically

B. To permanently increase table throughput

C. To handle sudden spikes in traffic smoothly

D. To reduce storage costs

Solution

1. Step 1: Understand burst capacity concept

   Burst capacity allows DynamoDB to use unused capacity from earlier low traffic periods.

2. Step 2: Identify its main use

   This helps handle sudden traffic spikes smoothly without extra setup.

3. Final Answer:

   To handle sudden spikes in traffic smoothly -> Option C

4. Quick Check:

   Burst capacity = handle spikes [OK]

Hint: Burst capacity smooths sudden traffic spikes [OK]

Common Mistakes:

• Thinking burst capacity permanently increases throughput
• Confusing burst capacity with backup or storage features
• Assuming manual code is needed to use burst capacity

2. Which of the following statements about DynamoDB burst capacity is syntactically correct?

easy

A. BurstCapacity: enabled

B. ProvisionedThroughput: { ReadCapacityUnits: 5, WriteCapacityUnits: 5 }

C. EnableBurstCapacity = true

D. SetBurstCapacity(5)

Solution

1. Step 1: Check valid DynamoDB syntax

   ProvisionedThroughput with ReadCapacityUnits and WriteCapacityUnits is valid for table setup.

2. Step 2: Identify invalid options

   Options B, C, and D are not valid DynamoDB syntax or parameters.

3. Final Answer:

   <code>ProvisionedThroughput: { ReadCapacityUnits: 5, WriteCapacityUnits: 5 }</code> -> Option B

4. Quick Check:

   Valid syntax = ProvisionedThroughput: { ReadCapacityUnits: 5, WriteCapacityUnits: 5 } [OK]

Hint: Only ProvisionedThroughput syntax is valid here [OK]

Common Mistakes:

• Assuming burst capacity needs explicit enabling syntax
• Using incorrect parameter names
• Confusing configuration with method calls

3. Consider a DynamoDB table with provisioned read capacity of 10 units. The table has been idle for a while, accumulating unused capacity. Suddenly, a spike causes 15 read requests per second. What will happen?

medium

A. The table will reject all requests during the spike

B. The table will throttle all requests above 10 units immediately

C. The table will automatically increase provisioned capacity to 15 units

D. The table will use burst capacity to handle some requests above 10 units

Solution

1. Step 1: Understand idle capacity accumulation

   Unused capacity from idle periods accumulates as burst capacity credits.

2. Step 2: Apply burst capacity during spike

   When requests exceed provisioned units, DynamoDB uses burst capacity to handle some extra requests smoothly.

3. Final Answer:

   The table will use burst capacity to handle some requests above 10 units -> Option D

4. Quick Check:

   Burst capacity handles spikes above provisioned [OK]

Hint: Burst capacity covers temporary spikes above provisioned [OK]

Common Mistakes:

• Thinking DynamoDB instantly throttles above provisioned units
• Assuming automatic permanent capacity increase
• Believing all requests are rejected during spikes

4. You notice your DynamoDB table is throttling requests during a traffic spike, even though it was idle before. What is the most likely cause?

medium

A. Burst capacity credits were already used up before the spike

B. Provisioned throughput is set too high

C. Burst capacity must be manually enabled

D. The table is in on-demand mode

Solution

1. Step 1: Analyze burst capacity usage

   Burst capacity depends on unused capacity credits accumulated during idle times.

2. Step 2: Reason about throttling cause

   If credits are used up, the table cannot handle spikes beyond provisioned throughput, causing throttling.

3. Final Answer:

   Burst capacity credits were already used up before the spike -> Option A

4. Quick Check:

   Throttling = no burst credits left [OK]

Hint: No burst credits means throttling during spikes [OK]

Common Mistakes:

• Thinking burst capacity needs manual enabling
• Assuming high provisioned throughput causes throttling
• Confusing on-demand mode with provisioned burst capacity

5. A DynamoDB table has a provisioned write capacity of 20 units. It was idle for 10 minutes, then suddenly receives 50 write requests per second for 1 minute. How does burst capacity affect this scenario?

hard

A. Burst capacity allows some requests above 20 units to succeed temporarily

B. Burst capacity automatically increases provisioned capacity to 50 units

C. Burst capacity allows all 50 requests to succeed without throttling

D. Burst capacity does not apply to write requests

Solution

1. Step 1: Understand burst capacity accumulation

   Idle time accumulates unused write capacity credits that can be used in bursts.

2. Step 2: Apply burst capacity during spike

   During the spike, burst capacity allows handling some requests above provisioned 20 units temporarily, but not all 50.

3. Final Answer:

   Burst capacity allows some requests above 20 units to succeed temporarily -> Option A

4. Quick Check:

   Burst capacity = temporary extra writes above provisioned [OK]

Hint: Burst capacity helps some writes above provisioned temporarily [OK]

Common Mistakes:

• Assuming burst capacity handles all spike requests fully
• Thinking burst capacity increases provisioned throughput permanently
• Believing burst capacity applies only to reads