Database Design • Key-Value Stores (Redis, DynamoDB)Easy⏱️ ~3 min
What Are Key Value Stores and When Should You Use Them?
Key value stores map a unique key to an opaque value, enabling constant time lookups in the common case. The access pattern is beautifully simple: get(key) returns value, put(key, value) stores it. This simplicity unlocks extreme throughput and low tail latency. A single Redis shard sustains 100,000 to 500,000 operations per second on commodity hardware with sub millisecond p50 latency and low single digit millisecond p99 latency.
The tradeoff is deliberate. Key value stores sacrifice rich queries, joins, and multi item transactions for predictable performance and horizontal scalability. Facebook's memcache deployment achieves over 90% hit rates with sub millisecond reads, reducing MySQL read load by an order of magnitude. Values are often tens to hundreds of bytes, though many systems impose item size caps around 1 MB and encourage storing large blobs in object storage with pointers in the key value store.
Two broad families exist. In memory key value caches like Redis optimize for microsecond to sub millisecond access at 10 to 100 times higher cost per GB month compared to disk. Disk backed key value stores like DynamoDB and Cassandra use Log Structured Merge trees (LSM trees) for high write throughput and durability, delivering single to tens of milliseconds latency. DynamoDB reports handling over 100 million requests per second during Prime Day with single digit millisecond median latencies.
Use key value stores when access is dominated by key based gets and puts with simple per item operations: sessions, idempotency keys, feature flags, rate limits, leaderboards, and counters. Prefer relational databases when you need multi item transactions or joins. Choose document databases when you need flexible schema with secondary indexes. Select graph databases for multi hop traversals.
💡 Key Takeaways
•Key value stores trade complex queries for predictable performance: no joins or multi item transactions but constant time lookups at 100,000+ operations per second per shard
•In memory systems like Redis cost 10 to 100 times more per GB but deliver sub millisecond latency versus disk backed systems at 5 to 10 milliseconds
•Production scale examples: DynamoDB handles 100 million requests per second during Prime Day, Facebook memcache achieves over 90% hit rates reducing database load by 10x
•Best for simple access patterns: sessions, rate limits, feature flags, counters, and leaderboards where you lookup by exact key
•Values typically tens to hundreds of bytes with 1 MB caps; store large blobs externally in object storage and keep pointers in key value store
📌 Examples
Amazon shopping cart uses Dynamo style key value stores with tunable consistency (N=3 replicas, R=W=2 quorum) maintaining 99.9th percentile latencies under 300ms during failures
Twitter Manhattan stores trillions of entities serving millions of requests per second for timelines and social graphs with automatic sharding and multi datacenter replication
Uber uses Redis clusters for rate limiting with sub millisecond updates, sharded counters to avoid hot keys, and per cell isolation to prevent cascading throttles