What if your database could magically handle any traffic without you lifting a finger?
Table capacity modes (on-demand vs provisioned) in DynamoDB - When to Use Which
Start learning this pattern below
Jump into concepts and practice - no test required
Imagine you run a small online store and you keep track of orders using a simple spreadsheet. When many customers buy at once, the spreadsheet slows down or crashes because it can't handle the sudden rush.
Manually guessing how many orders will come in each hour is hard. If you guess too low, your system gets overwhelmed and slows down. If you guess too high, you waste money paying for unused capacity. This guessing game is stressful and error-prone.
Table capacity modes let you choose how your database handles traffic. With on-demand, it automatically adjusts to traffic spikes without you worrying. With provisioned, you set the capacity ahead, which can save money if traffic is steady. This way, your system stays fast and cost-effective.
Set capacity units manually and monitor constantly.Use 'on-demand' mode to auto-scale or 'provisioned' mode to pre-set capacity easily.
You can focus on growing your app while your database smoothly handles any traffic, big or small.
A ticket booking app uses on-demand mode during a popular concert sale to handle sudden huge traffic without crashing or delays.
Manual capacity planning is hard and risky.
On-demand mode auto-scales with traffic spikes.
Provisioned mode lets you save costs with steady traffic.
Practice
Solution
Step 1: Understand capacity modes in DynamoDB
DynamoDB offers two main capacity modes: on-demand and provisioned. On-demand mode automatically adjusts capacity based on traffic.Step 2: Identify the mode that adjusts automatically
On-demand mode charges per request and scales automatically without manual settings, unlike provisioned mode which requires fixed capacity.Final Answer:
On-demand mode -> Option AQuick Check:
Automatic scaling = On-demand mode [OK]
- Confusing provisioned mode as automatic
- Thinking reserved or manual modes exist
- Assuming manual capacity adjustment is automatic
Solution
Step 1: Recall AWS CLI syntax for provisioned capacity
Provisioned mode requires specifying read and write capacity units using --provisioned-throughput with ReadCapacityUnits and WriteCapacityUnits.Step 2: Match correct syntax option
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 uses the correct syntax. The --billing-mode PAY_PER_REQUEST and --capacity-mode ON_DEMAND options specify on-demand mode, while --read-write-capacity is invalid.Final Answer:
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 -> Option BQuick Check:
Provisioned throughput syntax = --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 [OK]
- Using PAY_PER_REQUEST flag for provisioned mode
- Confusing capacity mode flags
- Using invalid flags like --read-write-capacity
Solution
Step 1: Understand provisioned capacity limits
Provisioned mode sets fixed read/write capacity units. Here, 5 read units allow about 5 strongly consistent reads per second.Step 2: Analyze traffic exceeding capacity
Sending 20 read requests exceeds the provisioned 5 units. DynamoDB throttles excess requests instead of automatically scaling or switching modes.Final Answer:
Some read requests may be throttled due to exceeding capacity -> Option CQuick Check:
Exceeding provisioned units causes throttling [OK]
- Assuming automatic scaling in provisioned mode
- Thinking all requests always succeed
- Believing table switches modes automatically
aws dynamodb create-table --table-name MyTable --billing-mode PROVISIONED
But you forgot to specify provisioned throughput. What will happen?
Solution
Step 1: Check requirements for provisioned mode
Provisioned mode requires specifying ReadCapacityUnits and WriteCapacityUnits explicitly during table creation.Step 2: Understand AWS CLI behavior on missing parameters
Omitting provisioned throughput causes AWS CLI to return an error because required parameters are missing.Final Answer:
Table creation fails with an error about missing provisioned throughput -> Option DQuick Check:
Missing provisioned throughput causes creation error [OK]
- Assuming default capacity is assigned
- Thinking table switches to on-demand mode
- Believing capacity is unlimited without settings
Solution
Step 1: Analyze startup traffic pattern
Unpredictable spikes mean traffic varies a lot, so automatic scaling is important to avoid throttling or overpaying.Step 2: Evaluate capacity mode options for cost and performance
On-demand mode charges per request and scales automatically, ideal for unpredictable traffic and cost control. Provisioned mode requires manual adjustments and risks throttling or wasted capacity.Final Answer:
Use on-demand mode to automatically handle spikes and pay per request -> Option AQuick Check:
Unpredictable traffic = On-demand mode best [OK]
- Choosing high provisioned capacity wastes money
- Manually adjusting capacity is slow and error-prone
- Switching modes daily is not supported
