DynamoDB capacity modes (on-demand, provisioned) in AWS - Time & Space Complexity
When using DynamoDB, how fast your requests get handled depends on the capacity mode you choose.
We want to understand how the number of requests affects the work DynamoDB does in each mode.
Analyze the time complexity of handling multiple read requests in different capacity modes.
// Provisioned mode example
aws dynamodb put-item --table-name MyTable --item '{"ID": {"S": "1"}}'
aws dynamodb update-table --table-name MyTable --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5
// On-demand mode example
aws dynamodb put-item --table-name MyTable --item '{"ID": {"S": "2"}}'
// No capacity units set, DynamoDB scales automatically
This shows putting items into a table with provisioned and on-demand capacity modes.
Look at what happens when many requests come in.
- Primary operation: Handling each read or write request.
- How many times: Once per request, repeated for every request.
- Dominant factor: The number of requests determines how many operations DynamoDB must process.
As you send more requests, DynamoDB processes more operations.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | 10 requests handled |
| 100 | 100 requests handled |
| 1000 | 1000 requests handled |
Each request adds one more operation, so the work grows steadily with the number of requests.
Time Complexity: O(n)
This means the time to handle requests grows directly with how many requests you send.
[X] Wrong: "On-demand mode handles any number of requests instantly without delay."
[OK] Correct: Even on-demand mode processes each request one by one, so more requests still mean more work and time.
Understanding how request volume affects DynamoDB helps you design systems that stay fast and reliable as they grow.
"What if we batch multiple requests together? How would the time complexity change?"
Practice
Solution
Step 1: Understand on-demand mode behavior
On-demand mode automatically adjusts capacity to meet traffic demands without manual input.Step 2: Compare with provisioned mode
Provisioned mode requires fixed capacity settings, unlike on-demand.Final Answer:
It automatically scales to handle any workload without manual capacity planning. -> Option BQuick Check:
On-demand = auto scaling without setup [OK]
- Confusing on-demand with provisioned fixed capacity
- Thinking on-demand limits requests
- Assuming on-demand is cheaper for steady workloads
Solution
Step 1: Recall provisioned capacity syntax
Provisioned mode requires specifying ReadCapacityUnits and WriteCapacityUnits inside ProvisionedThroughput.Step 2: Check options for correct JSON structure
{ "ProvisionedThroughput": { "ReadCapacityUnits": 5, "WriteCapacityUnits": 10 } } matches the correct AWS DynamoDB API format for provisioned throughput.Final Answer:
{ "ProvisionedThroughput": { "ReadCapacityUnits": 5, "WriteCapacityUnits": 10 } } -> Option CQuick Check:
ProvisionedThroughput with Read/Write units = correct syntax [OK]
- Using CapacityMode for provisioned capacity
- Missing ProvisionedThroughput wrapper
- Incorrect property names like ReadUnits
Solution
Step 1: Understand provisioned capacity limits
Provisioned mode limits throughput to the set capacity units (5 writes per second here).Step 2: Analyze effect of exceeding capacity
Sending 20 writes exceeds 5 units, causing throttling of excess requests.Final Answer:
Some write requests are throttled because they exceed the provisioned write capacity. -> Option AQuick Check:
Provisioned mode throttles excess requests [OK]
- Assuming automatic capacity increase in provisioned mode
- Thinking on-demand mode applies automatically
- Believing all requests always succeed
Solution
Step 1: Identify cause of throttling
Throttling occurs because provisioned capacity is too low for peak traffic.Step 2: Choose immediate fix without downtime
Increasing provisioned capacity units can be done live without deleting the table.Final Answer:
Increase the provisioned read and write capacity units. -> Option DQuick Check:
Increase capacity units to reduce throttling [OK]
- Deleting and recreating table causes downtime
- Assuming switching to on-demand is instant and free
- Reducing item size does not fix capacity limits
Solution
Step 1: Understand startup's needs
They want to avoid throttling during spikes and save cost during low usage.Step 2: Compare capacity modes for unpredictable traffic
On-demand mode charges per request and auto scales instantly, ideal for unpredictable spikes.Step 3: Evaluate other options
Provisioned with auto scaling helps but requires setup and may lag; fixed capacity risks throttling or cost waste.Final Answer:
On-demand mode because it charges per request and scales instantly without manual setup. -> Option AQuick Check:
Unpredictable traffic = on-demand mode best [OK]
- Choosing fixed provisioned capacity for unpredictable traffic
- Assuming auto scaling is instant and always perfect
- Thinking on-demand has fixed request limits
Ready to prove it?
Pass the test and this pattern moves unknown
