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.