Redis

Redis (Remote Dictionary Server) is an in-memory data structure store that functions as a database, cache, message broker, and streaming engine. Created by Salvatore Sanfilippo in 2009, Redis began as a simple key-value store but evolved into something far more structurally ambitious: a single-threaded event-loop architecture that serves as a universal fast-access substrate for distributed systems. Unlike traditional databases that optimize for durability and complex queries, Redis optimizes for speed and structural diversity — supporting not just strings but lists, sets, sorted sets, hashes, bitmaps, hyperloglogs, geospatial indexes, and streams.

Architecture and the Single-Threaded Illusion

Redis's most controversial design choice is its single-threaded event loop. In an era when multi-core processors dominate, Redis processes all commands sequentially on one thread. This seems like a backward choice, but it is the source of Redis's predictability. By avoiding locks, context switches, and cache coherency traffic, Redis achieves microsecond-level latency that multi-threaded databases cannot match. The single thread is not a limitation but a deliberate sacrifice of throughput for determinism — a choice that only makes sense because Redis lives in memory, where the cost of a cache miss is measured in nanoseconds, not milliseconds.

The event loop itself is an instance of the Event Loop pattern: commands are read from client connections, dispatched to handlers, and responses are written back. Redis 6.0 introduced threaded I/O to handle network reads and writes in parallel, but command execution remains single-threaded. This hybrid model preserves the core invariant — no two commands execute simultaneously — while scaling network throughput.

Data Structures as Computational Primitives

Redis's real power lies not in its speed but in its data structures. A Redis list is not merely a storage mechanism; it is a distributed queue, a stack, or a capped collection depending on which commands you use. Redis Streams implement a Publish-Subscribe model with consumer groups, providing the building blocks for event sourcing and stream processing. Sorted sets with their range queries enable real-time leaderboards and time-series indexing. These structures are not afterthoughts; they are first-class citizens that transform Redis from a passive storage layer into an active computational substrate.

This design philosophy — providing primitives rather than solutions — makes Redis a platform rather than a product. It does not know what a "session cache" or a "job queue" is; it provides the data structures, and applications compose them into higher-level semantics. The Key-value store is the foundation, but Redis builds a cathedral on top of it.

Memory, Persistence, and the Trade-off That Never Goes Away

Redis operates primarily in memory, which makes it an In-memory Database — a category that trades durability for speed. But Redis does not ignore durability entirely. It provides two persistence mechanisms: RDB (point-in-time snapshots) and AOF (append-only logs of every write operation). RDB is efficient but risks data loss between snapshots. AOF is more durable but imposes a write-amplification cost that can bottleneck the event loop.

The real architectural tension in Redis is not between speed and durability but between speed and memory cost. As datasets grow, Redis confronts the Memory Wall: DRAM is expensive and finite. Redis addresses this through eviction policies (LRU, LFU, TTL-based expiration) and, more recently, Redis on Flash — which tiers cold data to SSD while keeping hot data in memory. This is not a true solution to the memory wall; it is a mitigation that acknowledges the fundamental physics of memory economics.

Redis in the Systems Landscape

Redis sits at the intersection of multiple architectural trends. In Google Cloud Run and other serverless platforms, Redis serves as the external state store that enables stateless containers to share mutable state. In microservices architectures, Redis acts as a service mesh for data: a fast, shared namespace that decouples services from each other's databases. In Unified Memory architectures, Redis's memory-centric design philosophy rhymes with the broader industry shift toward treating memory as the primary computational resource rather than a scarce cache for disk.

Redis also functions as a distributed systems primitive. Redis Sentinel provides high availability through leader election and failover. Redis Cluster implements automatic sharding across nodes, partitioning the key space into 16384 hash slots. These distributed features are not bolted on; they are extensions of the core philosophy that Redis is not a database but a computational fabric.

Redis is often misunderstood as a database that happens to be fast. The truth is the opposite: Redis is a speed architecture that happens to store data. Its single-threaded event loop, its memory-first design, its data-structure primitives — all are consequences of a deeper conviction that latency is the fundamental constraint of distributed systems, and that the database should be optimized not for the questions you ask but for the speed at which you receive answers. The relational model asks "what do you want to know?" Redis asks "how fast do you need to know it?" And in the architecture of real-time systems, that second question is the only one that matters.