DynamoDB
Serverless key-value / document store partitioned by key; capacity in RCUs/WCUs.
Problem it solves: Simple access patterns at very high scale don't need relational features.
Where it sits: Behind services.
When to use
- Access purely by key at high QPS.
When not to use
- Ad-hoc queries and multi-row transactions.
Failure modes
- Hot keys overload one partition.
- Eventual consistency surprises readers.
Metrics to watch
- Partition throughput
- Throttled requests
- p99 latency
Alternatives
- Sharded SQL
Configuration in Labs (illustrative defaults)
- Capacity per instance (req/s) = 20000 — Maximum requests one instance completes per second before it saturates.
- Write capacity (primary) (writes/s) = 10000 — Writes the single primary can absorb per shard. Replicas do not add write capacity.
- Read replicas (count) = 2 — Each replica adds one instance of read capacity. Replication lag is not modelled numerically.
- Shards (count) = 4 — Partitions; each multiplies read and write capacity assuming keys spread evenly (no hot key).
- Base service time (ms) = 3 — Processing time per request at zero load. Queueing adds to this as utilisation rises.
Vendor examples (pattern only): AWS managed service. Simulated as a generic “Key-value / wide-column store”.