Partition Keys Decide Placement, Not Just Uniqueness

Every DynamoDB item lives on a specific physical partition — a fixed slice of storage and throughput capacity — determined by hashing the item’s partition key (also called the hash key). This is the single most consequential design decision in any DynamoDB table: the partition key isn’t just an identifier, it’s the sharding function for your entire dataset. Two items with the same partition key always land on the same partition; items with different partition keys are spread across many partitions by DynamoDB’s internal hashing.

A sort key (range key) is optional but powerful — items sharing a partition key are stored together, ordered by sort key, which is what makes range queries like “all orders for customer X between two dates” efficient without scanning the whole table.

Capacity Modes: Provisioned vs. On-Demand

flowchart TB
    APP[Application]
    RR[Request Router]
    subgraph PARTITIONS["Storage Partitions (replicated x3 across AZs)"]
        P1[Partition 1 - Leader]
        P1R1[Replica AZ-b]
        P1R2[Replica AZ-c]
    end
    GSI[(Global Secondary Index)]
    STREAM[DynamoDB Streams]
    LAMBDA[Lambda Consumer]
    DAX[DAX Cache Cluster]
    CW[CloudWatch Metrics]

    APP -->|cacheable read| DAX --> RR
    APP -->|write / strong read| RR
    RR -->|hash partition key| P1
    P1 -->|Paxos consensus| P1R1
    P1 -->|Paxos consensus| P1R2
    P1 -->|async propagate| GSI
    P1 -->|change events| STREAM --> LAMBDA
    P1 --> CW
    

Note the asymmetry: writes and strongly consistent reads always go to the partition leader; DAX sits in front of the router for read-heavy, cache-friendly access patterns; and GSIs update asynchronously, meaning a GSI read can briefly lag behind the base table under heavy write load.

You may likeAmazon VPC→

Write Path: Consensus Before Acknowledgment

Eventually Consistent vs. Strongly Consistent Reads

By default, a GetItem or Query call returns an eventually consistent read, which may be served by any replica — including one that hasn’t yet received the very latest write, though the propagation delay is typically well under a second. Setting ConsistentRead=true forces the read to go to the leader replica, guaranteeing you see the most recent successful write, at roughly double the read capacity cost and slightly higher latency.

flowchart LR
    A[Item Written] --> B[Base Table Partition]
    B -->|async| C[GSI Update]
    B -->|sync, same partition| D[LSI Update]
    B -->|change log| E[DynamoDB Streams - 24hr retention]
    E --> F[Lambda / Kinesis Consumer]
    B -->|TTL attribute expires| G[Automatic Deletion]
    G --> E
    

Time to Live (TTL) lets you mark an attribute as an expiry timestamp; DynamoDB then automatically deletes expired items in the background, at no additional write-capacity cost, typically within 48 hours of expiry. TTL deletions still appear as delete events on Streams, which is how downstream systems (e.g., archiving expired sessions to S3) stay in sync without polling.

Adaptive Capacity and Hot Partitions

DynamoDB’s adaptive capacity feature automatically redistributes throughput toward partitions receiving disproportionate traffic, isolating a hot partition key from throttling the rest of the table — but it operates within limits, and a sufficiently skewed access pattern (e.g., one celebrity user’s ID receiving 90% of a social app’s write traffic) can still throttle even with adaptive capacity active. This is why write-heavy, highly skewed workloads often use write sharding — appending a random suffix to a hot partition key to spread writes across multiple physical partitions, then fanning in reads across the shards.

Lyft’s Ride-Matching at Scale

Lyft uses DynamoDB for latency-sensitive components of its ride-matching system, where single-digit-millisecond reads and writes at massive concurrent scale during peak ride-hailing demand directly affect how quickly a rider gets matched with a nearby driver — a workload pattern DynamoDB’s partitioned architecture is purpose-built to serve.

Every DynamoDB table is automatically replicated synchronously across three Availability Zones within a region by default — there is no “Single-AZ mode” to opt out of, unlike some other AWS data services. For multi-region resilience, Global Tables replicate a table across multiple AWS Regions using a multi-active, last-writer-wins conflict resolution model.