Why DynamoDB capacity modes (on-demand, provisioned) in AWS? - Purpose & Use Cases

The Big Idea

What if your database could magically handle any number of users without you worrying about it?

The Scenario

Imagine you run a busy online store and you have to guess how many customers will visit each hour. You set up your database to handle that many shoppers manually. But some hours are quiet, and others are crazy busy. You have to keep changing settings all the time to keep up.

The Problem

Manually adjusting database capacity is slow and tricky. If you guess too low, your store slows down or crashes. Guess too high, and you waste money paying for unused capacity. It's stressful and easy to make mistakes that hurt your business.

The Solution

DynamoDB capacity modes let you choose how your database handles traffic automatically. On-demand mode adjusts instantly to any number of requests without you lifting a finger. Provisioned mode lets you set a steady capacity if you expect predictable traffic, saving money. Both take the guesswork and hassle away.

Before vs After

✗ Before

Update capacity settings every hour based on traffic reports

✓ After

Set DynamoDB to on-demand mode and forget about capacity changes

What It Enables

You can focus on growing your app while DynamoDB smoothly handles any traffic spikes or quiet times without manual work.

Real Life Example

A mobile game suddenly becomes popular overnight. With on-demand capacity, the database scales instantly to support millions of players without downtime or extra setup.

Key Takeaways

Manual capacity management is slow, error-prone, and costly.

DynamoDB capacity modes automate scaling to match your app's needs.

On-demand mode is great for unpredictable traffic; provisioned mode saves cost with steady traffic.

Practice

1. What is the main advantage of using DynamoDB's on-demand capacity mode?

easy

A. It offers a lower cost for steady, predictable workloads.

B. It automatically scales to handle any workload without manual capacity planning.

C. It requires you to set fixed read and write capacity units.

D. It limits the number of requests per second to a fixed amount.

Solution

1. Step 1: Understand on-demand mode behavior

   On-demand mode automatically adjusts capacity to meet traffic demands without manual input.

2. Step 2: Compare with provisioned mode

   Provisioned mode requires fixed capacity settings, unlike on-demand.

3. Final Answer:

   It automatically scales to handle any workload without manual capacity planning. -> Option B

4. Quick Check:

   On-demand = auto scaling without setup [OK]

Hint: On-demand means auto scale, no manual setup needed [OK]

Common Mistakes:

• Confusing on-demand with provisioned fixed capacity
• Thinking on-demand limits requests
• Assuming on-demand is cheaper for steady workloads

2. Which of the following is the correct way to specify provisioned capacity in a DynamoDB table creation JSON?

easy

A. { "Throughput": { "Reads": 5, "Writes": 10 } }

B. { "CapacityMode": "ON_DEMAND" }

C. { "ProvisionedThroughput": { "ReadCapacityUnits": 5, "WriteCapacityUnits": 10 } }

D. { "ReadUnits": 5, "WriteUnits": 10 }

Solution

1. Step 1: Recall provisioned capacity syntax

   Provisioned mode requires specifying ReadCapacityUnits and WriteCapacityUnits inside ProvisionedThroughput.

2. Step 2: Check options for correct JSON structure

   { "ProvisionedThroughput": { "ReadCapacityUnits": 5, "WriteCapacityUnits": 10 } } matches the correct AWS DynamoDB API format for provisioned throughput.

3. Final Answer:

   { "ProvisionedThroughput": { "ReadCapacityUnits": 5, "WriteCapacityUnits": 10 } } -> Option C

4. Quick Check:

   ProvisionedThroughput with Read/Write units = correct syntax [OK]

Hint: Provisioned capacity uses ProvisionedThroughput with Read/Write units [OK]

Common Mistakes:

• Using CapacityMode for provisioned capacity
• Missing ProvisionedThroughput wrapper
• Incorrect property names like ReadUnits

3. Given a DynamoDB table in provisioned mode with 5 read capacity units and 5 write capacity units, what happens if your application suddenly sends 20 write requests per second?

medium

A. Some write requests are throttled because they exceed the provisioned write capacity.

B. All 20 write requests succeed immediately without throttling.

C. DynamoDB automatically increases write capacity to 20 units instantly.

D. The table switches automatically to on-demand mode to handle the load.

Solution

1. Step 1: Understand provisioned capacity limits

   Provisioned mode limits throughput to the set capacity units (5 writes per second here).

2. Step 2: Analyze effect of exceeding capacity

   Sending 20 writes exceeds 5 units, causing throttling of excess requests.

3. Final Answer:

   Some write requests are throttled because they exceed the provisioned write capacity. -> Option A

4. Quick Check:

   Provisioned mode throttles excess requests [OK]

Hint: Provisioned mode throttles requests above set capacity [OK]

Common Mistakes:

• Assuming automatic capacity increase in provisioned mode
• Thinking on-demand mode applies automatically
• Believing all requests always succeed

4. You configured a DynamoDB table with provisioned capacity: 10 read units and 10 write units. Your application experiences throttling errors during peak hours. What is the best immediate fix to reduce throttling without downtime?

medium

A. Switch the table to on-demand capacity mode.

B. Reduce the size of items stored in the table.

C. Delete and recreate the table with higher capacity.

D. Increase the provisioned read and write capacity units.

Solution

1. Step 1: Identify cause of throttling

   Throttling occurs because provisioned capacity is too low for peak traffic.

2. Step 2: Choose immediate fix without downtime

   Increasing provisioned capacity units can be done live without deleting the table.

3. Final Answer:

   Increase the provisioned read and write capacity units. -> Option D

4. Quick Check:

   Increase capacity units to reduce throttling [OK]

Hint: Increase provisioned units live to fix throttling fast [OK]

Common Mistakes:

• Deleting and recreating table causes downtime
• Assuming switching to on-demand is instant and free
• Reducing item size does not fix capacity limits

5. A startup expects unpredictable traffic spikes and wants to minimize cost during low usage while avoiding throttling during spikes. Which DynamoDB capacity mode should they choose and why?

hard

A. On-demand mode because it charges per request and scales instantly without manual setup.

B. Provisioned mode with auto scaling enabled to adjust capacity automatically.

C. Provisioned mode with fixed capacity to control costs strictly.

D. On-demand mode but with a fixed maximum request limit to save costs.

Solution

1. Step 1: Understand startup's needs

   They want to avoid throttling during spikes and save cost during low usage.

2. Step 2: Compare capacity modes for unpredictable traffic

   On-demand mode charges per request and auto scales instantly, ideal for unpredictable spikes.

3. Step 3: Evaluate other options

   Provisioned with auto scaling helps but requires setup and may lag; fixed capacity risks throttling or cost waste.

4. Final Answer:

   On-demand mode because it charges per request and scales instantly without manual setup. -> Option A

5. Quick Check:

   Unpredictable traffic = on-demand mode best [OK]

Hint: Unpredictable spikes? Choose on-demand for auto scaling [OK]

Common Mistakes:

• Choosing fixed provisioned capacity for unpredictable traffic
• Assuming auto scaling is instant and always perfect
• Thinking on-demand has fixed request limits