Amazon DynamoDB Deep Dive — Partitioning & Capacity Modes

Recap: From Standby Databases to Partitioned Tables

Foundations You'll Need Today

1. Why This Is on the Exam

DynamoDB appears in SAP-C02 scenarios far more often than its share of the AWS catalog would suggest, and almost never as a trivia question about API names. It shows up because it is the answer to a specific class of requirement that relational databases cannot satisfy: single-digit-millisecond latency at a scale where the request rate is unpredictable, the schema is not fully known in advance, and the operational team does not want to run a database fleet. When a scenario says "millions of requests per second," "globally distributed users," or "no capacity planning," DynamoDB is usually the intended answer, and the distractors are usually RDS or Aurora dressed up with read replicas.

The reason the exam keeps returning to partitioning is that partitioning is where DynamoDB stops being a managed service and starts being a design decision you own. AWS manages the hardware, the replication, the patching, and the partition splitting. It does not manage your key choice. A table with a well-distributed partition key will absorb whatever throughput you provision; the same table with a low-cardinality key will throttle at a fraction of that capacity while CloudWatch shows the table-level metrics looking healthy. That gap between what the table is configured to do and what it can actually do is the single most reliable source of DynamoDB scenario questions.

This maps most directly to Domain 2, Design Resilient Architectures, because throttling is a resilience failure that looks like a capacity failure. It also touches Domain 1 through the multi-account and multi-region patterns that Global Tables enable, and Domain 4 because capacity mode selection is one of the largest single line items in a high-volume workload's bill. The exam expects you to reason about all three at once: a key design that survives a hot-partition event, a capacity mode that matches the traffic shape, and a cost profile that does not require a human to tune it every week.

2. How Partitioning Actually Works

A DynamoDB table is not a single logical store that happens to be distributed. It is a collection of partitions, each of which is an independent unit of storage and throughput backed by its own set of replicas across Availability Zones. When you write an item, DynamoDB computes a hash of the partition key value and uses that hash to decide which partition owns the item. Every item with the same partition key lands on the same partition, permanently, for as long as the table exists. This is why the partition key is sometimes called the hash key: it is literally the input to the function that selects the partition.

The consequence that matters operationally is that throughput is provisioned at the table level but enforced at the partition level. If you provision 10,000 write capacity units on a table, DynamoDB does not hand each partition an equal share and let you borrow from your neighbors. Each partition has a ceiling, and a request that targets a partition already at its ceiling is throttled even though the table as a whole is nowhere near its limit. The table-level CloudWatch metrics will show consumed capacity well below provisioned capacity while your application receives ProvisionedThroughputExceededException, which is the signature of a hot partition and the reason table-level dashboards are insufficient for DynamoDB.

DynamoDB does adapt. When a partition grows beyond a size threshold or sustains throughput above a threshold, the service splits it into two child partitions and redistributes the key ranges. This is automatic and invisible, but it is not instantaneous, and it does not help with a hot key. Splitting a partition whose load comes from a single partition key value produces two partitions where one of them still owns that value and still receives all the traffic. Adaptive capacity, the mechanism that shifts unused throughput toward busy partitions, has the same limitation: it can move budget between partitions, but it cannot split a single key's traffic across partitions, because the hash function is deterministic and every request for that key resolves to the same place.

Sort keys change the picture in a way that is easy to miss. Within a partition, items are stored sorted by the sort key, and a composite primary key of partition key plus sort key lets you query ranges efficiently with Query rather than scanning. But the sort key does not participate in partition selection. Two items with the same partition key and different sort keys live on the same partition, so a table keyed on a low-cardinality attribute is just as hot whether or not it has a sort key. The sort key buys you query flexibility and item collection locality; it does not buy you distribution.

3. The Core Decision Boundary: Key Cardinality

Almost every DynamoDB scenario question reduces to a single judgment: does the proposed partition key distribute writes and reads evenly across the key space, or does it concentrate them? The exam will hand you a table design, describe a symptom, and expect you to connect the two. The symptom is almost always throttling under load that the provisioned capacity should have absorbed. The cause is almost always a key whose distinct value count is small relative to the request volume, or a key whose value distribution is skewed by the access pattern rather than by the data itself.

Cardinality is the first test. A partition key with five distinct values can only ever spread load across five partitions, no matter how many partitions the table has. A partition key with millions of distinct values spreads naturally. The second test is access skew, which is subtler: a key can have high cardinality and still be hot if the application's traffic concentrates on a small subset of values. A table keyed on customer ID is well distributed in storage but becomes a hot partition if one customer generates most of the traffic, which is exactly the shape of a multi-tenant SaaS workload with a whale account. The third test is whether the key is derived from something that changes over time, because a monotonically increasing key such as a timestamp concentrates all current writes on the newest partition.

The standard remedy is a composite or derived key that adds entropy without destroying query patterns. Appending a random suffix or a shard identifier to the partition key spreads writes across a known number of partitions, at the cost of turning a single-item read into a scatter-gather across those shards. Prepending a coarse time bucket to a timestamp key spreads writes across buckets while keeping range queries within a bucket efficient. The tradeoff is always the same: entropy in the partition key buys write distribution and costs read simplicity.

4. Capacity Modes and Their Tradeoffs

Once the key design is settled, the next decision is how the table pays for throughput. Provisioned mode asks you to declare a read and write capacity budget up front, expressed in capacity units, and bills you for that budget whether or not you consume it. On-demand mode asks for nothing up front and bills per request, scaling automatically to whatever traffic arrives. The two modes are not a quality ranking; they are a match between a traffic shape and a billing model, and the exam will describe a traffic shape and expect you to pick the mode that fits it.

Provisioned mode is cheaper per unit of throughput, which is why it is the right answer for steady, predictable workloads. Its weakness is that the declared budget is a hard ceiling unless you enable auto scaling, and auto scaling reacts to CloudWatch metrics that are themselves averaged over a window. A workload that doubles in traffic within a minute will throttle before auto scaling catches up, because the scaling policy needs the metric to move and the alarm to fire before it can raise the ceiling. Provisioned mode with auto scaling is therefore a good fit for workloads with gradual, forecastable variation — a daily traffic curve, a weekly cycle — and a poor fit for spiky or unpredictable ones.

On-demand mode removes the ceiling entirely and the capacity planning along with it. You pay per request, at a rate that is higher than provisioned capacity for the same volume, and you get instant adaptation to any traffic shape including a tenfold spike in seconds. The tradeoff is cost predictability: a workload with a stable, high baseline will pay noticeably more on-demand than it would provisioned, and the bill scales linearly with traffic rather than being capped by a reservation. On-demand also has a warm-up consideration for tables that have never seen high throughput, since the service adjusts its internal partitioning to observed traffic.

There is a third path that the exam tests less often but that appears in cost-optimization scenarios: provisioned mode with reserved capacity, which is a commitment-based discount on a baseline of provisioned throughput. It only makes sense on top of a provisioned table whose baseline is stable enough to commit to, and it does not change the throttling behavior of the table at all. The decision sequence is therefore: pick the key design first, then pick the mode from the traffic shape, then consider a reservation only if the baseline is genuinely flat.

5. Sizing, Limits and Quotas

DynamoDB's numbers matter because scenario questions frequently hinge on whether a proposed design fits inside a documented limit. The unit of measurement is the capacity unit, and it is defined differently for reads and writes. One write capacity unit covers one write per second for an item up to 1 KB in size; larger items consume proportionally more, so a 3 KB item costs 3 write capacity units per write. One read capacity unit covers one strongly consistent read per second for an item up to 4 KB, or two eventually consistent reads per second for the same size. The asymmetry between the 1 KB write and 4 KB read unit is worth memorizing because it is the kind of detail a distractor will get wrong.

Item size is capped at 400 KB, which is a hard limit and a common reason a design has to be reworked — large blobs belong in S3 with the object key stored in DynamoDB, not in the item itself. Each item is limited to 400 KB including attribute names, and attribute names count toward the size, which is why short attribute names are a real optimization on large tables. A single Query or Scan operation returns at most 1 MB of data before paginating, so a query that needs more must loop on LastEvaluatedKey. A single BatchWriteItem call handles up to 25 items and a BatchGetItem up to 100 items, and neither is atomic across the batch.

On the partition side, the numbers that drive hot-partition behavior are the per-partition throughput ceilings and the split thresholds. A partition can sustain a bounded amount of read and write throughput, and when a table's provisioned capacity implies more partitions than the data volume would naturally create, DynamoDB splits partitions to spread the provisioned capacity. The practical implication is that a table with high provisioned capacity and a low-cardinality key ends up with many partitions, only a few of which receive traffic. Adaptive capacity can shift some budget toward the busy partitions, but it cannot exceed the per-partition ceiling, which is why a single hot key throttles regardless of how much capacity the table has.

Secondary indexes have their own capacity and their own limits. A local secondary index shares the partition key of the base table and therefore inherits its distribution — a hot base partition means a hot LSI. A global secondary index has its own partition key and its own provisioned capacity, which means a GSI can be hot even when the base table is healthy, and a GSI write consumes capacity on both the index and the base table. The number of GSIs per table is limited, and a GSI's key design deserves the same scrutiny as the base table's, because a poorly chosen GSI key is one of the more common causes of throttling in tables whose base key is fine.

6. Failure Modes and What They Look Like in Production

The canonical DynamoDB failure is throttling, and its signature is specific enough to diagnose quickly. The application receives ProvisionedThroughputExceededException or, in on-demand mode, RequestLimitExceeded, while the table-level ConsumedWriteCapacityUnits metric sits comfortably below ProvisionedWriteCapacityUnits. That combination — errors at the client, headroom at the table — is the fingerprint of a hot partition or a hot key, and it is the first thing to check when a DynamoDB-backed service starts failing under load. If the table-level metric is at or above provisioned capacity instead, the problem is genuine under-provisioning and the fix is a capacity change, not a key redesign.

The second failure mode is the slow query that is not a query at all. A Scan operation reads every item in the table and consumes capacity proportional to table size, so a Scan added for an administrative report can consume the entire table's throughput budget and starve production traffic. The symptom is a broad latency increase across all operations rather than errors on one key, and the diagnostic move is to look at which operations are consuming capacity in the CloudWatch metrics and in CloudTrail data events. Scans in production are almost always a design smell; the fix is a GSI that supports the access pattern the scan was serving.

The third failure mode is the GSI backpressure problem, which is easy to miss because the base table looks healthy. A GSI has its own write capacity, and if the index cannot keep up with writes to the base table, the base table's writes are throttled to protect the index. The symptom is write throttling on a table whose own write capacity is fine, and the diagnostic move is to check the index's consumed versus provisioned capacity. This is why GSI capacity should be provisioned with headroom, and why on-demand mode is attractive for tables with GSIs whose write patterns are hard to forecast.

The fourth failure mode is the retry storm. DynamoDB SDKs retry throttled requests with exponential backoff by default, which is correct behavior, but an application that also implements its own retry loop on top of the SDK's can multiply the request rate during an incident and turn a transient throttle into a sustained one. The symptom is a request rate that climbs during the incident rather than falling, and the diagnostic move is to check whether the application's retry logic is layered on top of the SDK's. The fix is to let the SDK handle retries and to add jitter and a circuit breaker at the application layer rather than a second retry loop.

7. The Operational and SRE Angle

DynamoDB's operational surface is smaller than a self-managed database's, but it is not zero, and the monitoring that matters is not the monitoring most teams set up first. Table-level consumed capacity and throttled request counts are the baseline, and they belong on a dashboard with alarms, but they are insufficient on their own because they cannot see a hot partition. The metrics that reveal hot-partition behavior are the ones broken out by operation and, where available, by key — and the practical substitute for per-key metrics is an application-level metric that records which partition key values are being accessed, sampled at a rate that keeps the metric cost reasonable.

The alarm design that works is a two-layer one. The first layer alarms on throttled requests at the table level, which catches genuine under-provisioning and GSI backpressure. The second layer alarms on the ratio of consumed to provisioned capacity sustained above a threshold, which catches the approach to a ceiling before requests start failing. Neither layer catches a hot partition on its own, so the third element is a synthetic or canary workload that exercises the highest-traffic key values on a schedule and reports latency, which turns a silent hot-partition condition into a visible one before customers see it.

The runbook shape follows from the failure modes. A throttle alarm should lead the responder through a fixed sequence: check whether table-level consumed capacity is at the ceiling, check whether a GSI is the bottleneck, check whether a Scan or an unbounded Query is consuming capacity, and only then look at key distribution. If the first three checks are clean, the incident is a hot key and the remediation is either a key redesign or, as a stopgap, a write-sharding layer in front of the table. Having that sequence written down matters because the instinct under pressure is to raise provisioned capacity, which does nothing for a hot partition and increases the bill.

From an SLO perspective, DynamoDB changes what you can promise. Because the service is multi-AZ by default and replicates synchronously within a region, availability SLOs are usually dominated by the application's own error handling rather than by the database's availability. Latency SLOs are dominated by item size and access pattern: a single-digit-millisecond p99 is achievable for small items accessed by primary key, and not achievable for large items or for queries that return many items. Writing an SLO that assumes uniform latency across all access patterns is a common way to end up with a permanently burning error budget.

8. Edge Cases and Exam Gotchas

The most frequently missed point is that a sort key does not improve partition distribution. Candidates who understand that low-cardinality partition keys are bad sometimes conclude that adding a sort key fixes it, which it does not — the partition key alone determines the partition. A related gotcha is that a GSI's partition key can be different from the base table's, which means a GSI can rescue an access pattern that the base key cannot serve, but it also means a GSI can introduce a new hot partition that the base table does not have.

Capacity unit arithmetic is a reliable source of wrong answers. Reads are measured in 4 KB blocks and writes in 1 KB blocks, strongly consistent reads cost twice an eventually consistent read of the same item, and transactional reads and writes cost double the equivalent non-transactional operation. A scenario that gives you an item size, a request rate, and a consistency requirement is asking you to do this arithmetic, and the distractors are usually the answers you get by using the wrong block size or forgetting the consistency multiplier.

Mode switching has a constraint worth remembering: a table can be switched between provisioned and on-demand, but not more than once in a 24-hour period. A scenario that proposes switching a table to on-demand for a flash sale and back afterward is testing whether you know that the switch back may have to wait. On-demand tables also have a warm-up behavior for tables that have never sustained high throughput, so a scenario that expects instant full-scale performance from a brand-new on-demand table is describing something the service does not guarantee.

Finally, the limits that show up as distractors: 400 KB maximum item size, 1 MB maximum returned per Query or Scan, 25 items per BatchWriteItem, 100 items per BatchGetItem, and the fact that a Query on a GSI is eventually consistent unless the index is configured otherwise. Each of these is a plausible-sounding constraint that a wrong answer will violate, and each is worth being able to state without looking it up.

9. DynamoDB vs. the Databases It Gets Confused With

The exam's DynamoDB distractors are usually Aurora or RDS, and the distinguishing question is almost always about access pattern and scale rather than about features. DynamoDB is a key-value and document store with a fixed set of access patterns defined at design time; Aurora is a relational engine that supports arbitrary SQL joins and ad hoc queries. If a scenario requires joins, aggregations across arbitrary dimensions, or a schema that changes shape frequently, DynamoDB is the wrong answer no matter how attractive its scale characteristics look. If a scenario requires single-digit-millisecond latency at a request rate that would overwhelm a relational primary, Aurora is the wrong answer no matter how familiar it is.

ElastiCache is the other frequent distractor, and the boundary is durability. A cache is a performance layer in front of a system of record; DynamoDB is a system of record. A scenario that describes losing cached data as acceptable is describing a cache, and a scenario that describes losing data as unacceptable is describing a database. DAX sits between the two — it is a cache for DynamoDB specifically, and it does not change the durability characteristics of the table underneath it.

Hands-on Lab: Redesigning a Hot Partition Key

Scenario Question Drills (20 min)

Peek into Tomorrow

Sources