Internals

Your table throttles while CloudWatch shows average utilization under 50%, and adaptive capacity sounds like a magic fix until one partition key still absorbs a disproportionate share of traffic. Without a mental model of physical partitions, those behaviors look random.

This section is the deep end: how partition keys hash to storage splits, how GSIs are separate partitioned structures, how the request router picks an endpoint, and where today's DynamoDB still rhymes with the original Dynamo paper. Read it after modeling and indexing click — it explains the rules the earlier sections handed you.

What you can do after

• Predict hot-key symptoms from hash distribution and item collection size.
• Explain why a GSI lags the base table and why you cannot strong-read your own GSI write.
• Describe adaptive capacity as redistribution, not unlimited burst on one key.
• Connect partition splits and storage layout to why Query stays local to one hash key.

Reading order

1. How partition keys work — hash key to partition assignment; the unit of throughput isolation.
2. Adaptive capacity — borrowing capacity across partitions; limits under sustained skew.
3. GSI internals — separate partitions, asynchronous propagation, storage overhead per index item.
4. Physical partitions — splits when collections grow; 10 GB LSI collection caps in context.
5. Storage internals — b-tree-ish local ordering inside a partition; what "sorted by sort key" means on disk.
6. Request routing — endpoints, DNS, and why clients should retry throttles with backoff.
7. From Dynamo paper to DynamoDB — historical lineage; which promises survived to the managed service.

A partition key value maps to one hash slot at a time; all items sharing that hash key live in one item collection until a split occurs. Write 10,000 events per second to PK = TENANT#acme and you concentrate WRUs on a handful of physical partitions even if the table has thousands. Adaptive capacity can shift surplus from quiet partitions, but sustained skew on one key still wins.

GSI propagation is asynchronous — typically within a fraction of a second under normal conditions, per AWS — with no ConsistentRead escape hatch on the index.

Practice in the workbench

Download DynoTable and open Settings on a table you know is skewed. Compare key structure with item counts per partition using a Query on a heavy tenant partition vs a quiet one.

In the SQL Workbench, GROUP BY the partition key (or a prefix extracted in SQL) over a bounded Scan or Query result to see which keys carry the most items on screen. That aggregation runs client-side on fetched rows — it does not scan the table for free.

The item size calculator helps explain why large item collections approach split thresholds. DynoTable does not expose CloudWatch metrics or partition heat maps; use AWS observability for fleet-wide heat and the curriculum for the model behind what you see.

Read internals after Indexes so GSI write amplification and eventual consistency are already familiar.