1Why is Redis single-threaded for command execution, and what advantage does this provide?
Vetora🔑Database Families
Key-Value Stores (Redis, DynamoDB)
Key-value stores provide O(1) lookups by mapping unique keys to values, offering the simplest and fastest data access pattern. Redis excels as an in-memory data structure server, while DynamoDB provides a fully managed, serverless key-value store with single-digit-millisecond latency at any scale.
Overview
Key-value stores are the simplest category of database, offering a fundamental abstraction: given a key, return the associated value. This simplicity is their greatest strength -- by constraining the access pattern to point lookups, key-value stores achieve performance characteristics that more complex data models cannot match. A well-designed key-value store can serve millions of operations per second with sub-millisecond latency because it avoids the overhead of query parsing, join planning, and schema enforcement that relational databases must perform.
Redis (Remote Dictionary Server) is the most widely used in-memory key-value store. What makes Redis exceptional is that it is not just a simple key-value map -- it is a data structure server. Values can be strings, hashes (field-value maps), lists, sets, sorted sets (with scores for ranking), HyperLogLog (probabilistic cardinality counting), streams (append-only logs), and bitmaps. Each data structure supports atomic operations: you can atomically increment a counter, push to a list, add to a sorted set, or execute multiple operations in a Lua script -- all without external locking. Redis is single-threaded for command execution (using I/O multiplexing for networking in Redis 7+), which eliminates lock contention and makes every operation inherently atomic. This architecture achieves 100K-500K operations per second on a single node.
DynamoDB, Amazon's fully managed key-value and document store, represents the opposite end of the operational spectrum. Where Redis requires you to manage instances, memory limits, persistence configuration, and replication, DynamoDB is serverless -- you define a table with a partition key (and optional sort key), and AWS handles provisioning, replication, backups, and scaling. DynamoDB achieves consistent single-digit-millisecond latency at any scale through automatic partitioning: data is distributed across partitions by hashing the partition key, and each partition is replicated across three availability zones. On-demand capacity mode automatically scales to handle traffic spikes without pre-provisioning. Global tables provide active-active multi-region replication with eventual consistency across regions and strong consistency within a region.
The key-value model's simplicity comes with an important constraint: you can only query by key. There are no JOINs, no ad-hoc filters on non-key attributes (without secondary indexes in DynamoDB, which have their own limitations), and no aggregation queries. This means the application must know exactly which key to look up, and data modeling revolves around designing keys that support the required access patterns. In DynamoDB, this means choosing partition keys with high cardinality to avoid hot partitions, and using sort keys to enable range queries within a partition. In Redis, this means designing key naming conventions (e.g., user:1234:session) that enable efficient access. The constraint is a feature, not a bug: by limiting what you can ask, key-value stores can answer those limited questions faster than any other data model.
Key Points
- 1O(1) average-case lookup by key makes key-value stores the fastest data access pattern. Redis serves sub-millisecond reads from memory; DynamoDB guarantees single-digit-millisecond reads from SSD at any scale.
- 2Redis data structures go beyond simple strings: sorted sets enable leaderboards, streams enable event sourcing, HyperLogLog enables cardinality estimation with 0.81% standard error using only 12 KB of memory, and pub/sub enables real-time messaging.
- 3Redis is single-threaded for command execution, making all operations inherently atomic without locks. Complex atomic operations are achieved through Lua scripting (EVAL) or Redis transactions (MULTI/EXEC), not distributed locks.
- 4DynamoDB partitions data by hashing the partition key across storage nodes. Choosing a high-cardinality partition key (like user_id) ensures even distribution; low-cardinality keys (like status) create hot partitions that throttle throughput.
- 5DynamoDB's on-demand capacity mode eliminates capacity planning by automatically scaling read and write capacity. Provisioned mode with auto-scaling is more cost-effective for predictable workloads, potentially saving 50-70% compared to on-demand.
- 6Redis persistence options -- RDB snapshots (point-in-time) and AOF (append-only file, operation log) -- trade durability for performance. For pure caching use cases, persistence can be disabled entirely for maximum throughput.
Simple Example
The Coat Check Room
A key-value store works like a coat check at a concert venue. You hand in your coat and receive a numbered ticket (the key). When you want your coat back, you present the ticket and the attendant retrieves it instantly -- they do not search through all coats, they go directly to your numbered hook (O(1) lookup). You cannot ask the attendant 'give me all blue coats' or 'how many coats were checked in after 8 PM' -- those would require scanning every hook. The coat check is optimized for one operation: given a ticket number, return the coat. Key-value stores make the same trade-off: blindingly fast lookups by key, but no ability to query by value.
Real-World Examples
Twitter uses Redis extensively for timeline caching, storing precomputed timelines as sorted sets where the score is the tweet timestamp. When a user opens Twitter, their timeline is read from Redis in sub-millisecond time rather than reconstructing it from the social graph and tweet tables. Twitter's Redis deployment handles over 100 billion operations per day across thousands of Redis instances, using Redis Cluster for horizontal sharding.
Amazon
Amazon uses DynamoDB for its shopping cart service, the very use case that inspired the original Dynamo paper (2007). Each cart is stored as a single DynamoDB item keyed by session or user ID, with cart items as a nested map attribute. DynamoDB's guaranteed single-digit-millisecond latency ensures that 'Add to Cart' never feels slow, even during peak events like Prime Day when DynamoDB processes over 89 million requests per second.
Discord
Discord uses Redis for online presence tracking (showing which users are online), rate limiting (using Redis's atomic INCR with TTL), and message caching for recent channel history. Redis's pub/sub feature distributes real-time events across Discord's gateway servers, notifying users of new messages, typing indicators, and presence changes. The combination of sub-millisecond latency and atomic operations makes Redis ideal for Discord's real-time communication requirements.
Trade-Offs
| Aspect | Description |
|---|---|
| Speed vs Query Flexibility | Key-value stores offer the fastest possible reads and writes by restricting access to point lookups by key. You cannot perform JOINs, aggregate queries, or filter by non-key attributes efficiently. DynamoDB's secondary indexes partially address this but add cost, latency, and eventual consistency. If your access patterns require ad-hoc queries, a relational database is a better fit. |
| In-Memory vs Persistent Trade-off | Redis operates in memory for maximum speed but is constrained by available RAM (and cost of memory). Data larger than memory requires Redis Cluster sharding or a persistent store like DynamoDB. DynamoDB stores data on SSD and handles datasets of any size but has higher per-operation latency (1-5ms) compared to Redis (0.1-0.5ms). |
| Managed vs Self-Operated | DynamoDB is fully managed -- no servers to provision, no replication to configure, no backups to schedule -- but you pay a premium per operation and give up control over hardware, query engine behavior, and data locality. Redis requires managing instances, memory limits, failover (Sentinel or Cluster), and persistence, but gives you full control and can be significantly cheaper at scale. |
| Consistency Model | Redis in single-node mode provides strong consistency for all operations. Redis Cluster provides strong consistency per slot but can lose acknowledged writes during failover (asynchronous replication to replicas). DynamoDB provides eventual consistency by default and strong consistency as an option per read, at the cost of 2x the read capacity units and potentially higher latency. |
Case Study
DynamoDB at Amazon Prime Day -- 89 Million Requests per Second
Scenario
Amazon Prime Day generates the highest traffic spike of the year, with hundreds of millions of shoppers browsing products and adding items to carts simultaneously. The shopping cart, product catalog lookups, and session management services must maintain single-digit-millisecond latency even at peak load. Traditional relational databases would require months of capacity planning and over-provisioning for a traffic spike that lasts 48 hours.
Solution
Amazon uses DynamoDB in on-demand capacity mode for Prime Day workloads, allowing tables to scale automatically from baseline traffic to peak without pre-provisioning. The shopping cart table uses user_id as the partition key for even distribution. DAX (DynamoDB Accelerator) provides a write-through caching layer for hot product catalog reads, reducing DynamoDB read load by 10x. Global tables replicate cart data across regions so users in Europe and Asia hit local endpoints rather than cross-region calls.
Outcome
During Prime Day 2023, DynamoDB processed over 89 million requests per second with single-digit-millisecond average latency and zero throttling events. The on-demand model meant Amazon paid only for the actual operations consumed rather than maintaining peak-capacity provisioning year-round. The DAX caching layer kept catalog read latency under 1ms and reduced DynamoDB read costs by over 80% for frequently accessed products.
Common Mistakes
- ⚠Using Redis as a primary database without persistence. If Redis crashes with persistence disabled or with infrequent RDB snapshots, all data since the last snapshot is lost. For data that cannot be rebuilt from another source, enable AOF with appendfsync everysec as a minimum durability guarantee.
- ⚠Choosing low-cardinality DynamoDB partition keys. Using a key like 'status' (with only a few possible values) concentrates all reads and writes on a small number of partitions, causing throttling even when the table's total capacity is sufficient. Choose keys with high cardinality like user_id or order_id.
- ⚠Storing large values in Redis without considering memory impact. A single Redis key holding a 10 MB JSON blob wastes memory and blocks the single-threaded event loop during serialization. Break large values into hashes or split across multiple keys.
- ⚠Not setting TTLs on cache entries in Redis. Without expiration, memory grows unbounded until the server hits maxmemory and begins evicting keys. Set explicit TTLs on all cache entries and configure a maxmemory-policy (allkeys-lru is a safe default).
Related Concepts
See Key-Value Stores (Redis, DynamoDB) in action
Explore system design templates that use key-value stores (redis, dynamodb) and run traffic simulations to see how these concepts perform under real load.
Browse TemplatesSee how key-value caching affects hit rates and tail latency
Metrics to watch
cache_hit_ratep99_latency_msthroughput_ops_sec
Test Your Understanding
2What is the primary risk of choosing a low-cardinality partition key in DynamoDB?
3Which Redis data structure would you use to implement a real-time leaderboard that ranks players by score?