Redis

Redis (REmote DIctionary Server) is the default answer to "which distributed cache?" — and much more than a cache. It is an in-memory server of data structures: strings, hashes, lists, sets, sorted sets, streams and more, each with atomic operations. BoxOffice uses it as the catalog cache, but also as the session store, the rate limiter, the waiting-room line and the "people viewing now" counter. Knowing what each structure costs, how Redis persists and replicates, and how Redis Cluster spreads keys is what lets you use it well — and recognise when it is the wrong tool.

What makes Redis fast

• Everything is in RAM. A read is a hash-table lookup plus a memory copy; disk is only used for persistence, in the background.
• One thread executes commands. Commands run one at a time on a single main thread (since Redis 6, separate I/O threads can handle network reads and writes). There are no locks inside the server, and every command is atomic: no other command runs in the middle of an INCR.
• Simple protocol, small values. Most commands are O(1) or O(log n). In the same data center, a round trip of a small GET costs a fraction of a millisecond, dominated by the network.

The single thread is also Redis's main constraint: one slow command (an O(n) scan of a big key, a long Lua script) blocks every client. Throughput per node is high — on the order of 100,000 simple commands per second or more on typical hardware, an illustrative figure you should verify with redis-benchmark on your own setup — and scaling beyond one node means Redis Cluster.

Redis, Valkey and the alternatives (2026)

In 2024 Redis changed from the open-source BSD license to source-available licenses (RSALv2/SSPLv1). In response, the Linux Foundation started Valkey, a fork of Redis 7.2 backed by several cloud providers, which stays BSD-licensed and protocol-compatible. In 2025, Redis 8 added the open-source AGPLv3 as a license option. For this course — and in most interviews — "Redis" means the protocol and data model, which Redis and Valkey share¹².

Data structures and what BoxOffice does with them

> SET boxoffice:catalog:event:42:v3 '{"id":42,"name":"Stadium Show"}' EX 300
OK
> TTL boxoffice:catalog:event:42:v3
(integer) 300
> HSET session:9f1c user 1017 roles fan cart 3
(integer) 3
> INCR views:event:42
(integer) 1
> ZADD waitingroom:42 1760695200123 fan:1017 1760695200456 fan:2203
(integer) 2
> ZRANK waitingroom:42 fan:2203
(integer) 1
> ZPOPMIN waitingroom:42 1
1) "fan:1017"
2) "1760695200123"
> PFADD visitors:event:42 fan:1017 fan:2203 fan:1017
(integer) 1
> PFCOUNT visitors:event:42
(integer) 2

The waiting room is a good example of choosing a structure: a sorted set with the arrival time (in milliseconds) as the score gives each fan their position in O(log n) (ZRANK), and lets the admission job take the next 500 fans in one command (ZPOPMIN waitingroom:42 500).

Round trips: pipelining and multi-key commands

At 0.5 ms per round trip, reading 100 keys one by one costs 50 ms. MGET (or pipelining — sending many commands without waiting for each reply) does it in about one round trip. A page that needs many cached objects should fetch them together.

Atomicity

Because commands run one at a time, a single command is atomic. For more than one command, Redis offers three tools:

A fixed-window rate limiter for the API gateway in two commands:

> INCR rl:client:abc:202610171000
(integer) 1
> EXPIRE rl:client:abc:202610171000 60 NX
(integer) 1

If the counter returned by INCR exceeds 100, the request is rejected. (EXPIRE ... NX sets the expiry only the first time. More refined algorithms — token bucket, sliding window — are in Traffic & Edge.)

A seat pre-hold in Redis — and why SQL still decides

During the flash sale, thousands of fans click the same good seats. A Redis pre-hold can reject most of the losers in microseconds, before they reach the database:

> SET hold:42:A-12 fan:1017 NX PX 600000
OK
> SET hold:42:A-12 fan:2203 NX PX 600000
(nil)

NX makes the set succeed only if nobody holds the key; PX 600000 releases it automatically after 10 minutes. The second fan gets nil immediately: "seat taken".

It is tempting to stop there. Do not. The fan who got OK still goes to the inventory service, which takes the hold in a PostgreSQL transaction with a constraint that makes double booking impossible (Databases — the double-booking bug). Redis is a fast filter; the database decides. Why:

• Redis replication is asynchronous: after a failover, the new primary may not have the hold that was just granted — two fans could both get OK (replication).
• Memory pressure, a FLUSHALL by mistake, or a cache restart without persistence erase holds silently.
• The order, the payment and the ticket live in SQL; the seat state must be in the same transaction as them.

If Redis loses a pre-hold, the worst case is that two fans reach the database and one of them loses there. Correctness never depended on Redis.

Persistence

Redis keeps data in memory but can write it to disk, so a restart does not start cold.

For a cache, RDB or nothing is usually enough. If you find yourself tuning appendfsync always, ask whether this data belongs in a database.

Replication and failover

A Redis primary can have several replicas that receive a stream of its writes. Replicas serve reads (slightly stale) and are candidates for promotion if the primary fails.

flowchart LR
    APP["catalog service"] -->|"writes and reads"| P[("Redis primary")]
    P -->|"async replication"| R1[("replica 1")]
    P -->|"async replication"| R2[("replica 2")]
    S1["Sentinel 1"] -.->|"monitor"| P
    S2["Sentinel 2"] -.->|"monitor"| P
    S3["Sentinel 3"] -.->|"monitor"| P
    S1 -.->|"quorum agrees: promote"| R1

• Replication is asynchronous: the primary acknowledges a write before the replicas have it. If the primary dies, the last acknowledged writes may be lost. WAIT numreplicas timeout makes a client wait until N replicas have its writes — it reduces the window but does not make Redis strongly consistent.
• Redis Sentinel is a group of processes (at least 3) that monitor the primary; when a quorum agrees it is down, they promote a replica and tell clients the new address. Failover takes seconds — the cache is unavailable or read-only meanwhile.
• min-replicas-to-write makes the primary refuse writes when it cannot reach enough replicas, limiting loss during a partition.

For a cache this is fine: a lost write is a future miss. For data that must not be lost, it is the reason to keep the source of truth in a database.

Redis Cluster

When one node is not enough — memory or throughput — Redis Cluster shards the keyspace over several primaries, each with its own replicas³.

• The keyspace is divided into 16,384 hash slots. A key's slot is CRC16(key) mod 16384.
• Each primary owns a set of slots (e.g. three primaries: 0–5460, 5461–10922, 10923–16383).
• Clients are cluster-aware: they cache the slot → node map and send each command directly to the right node. If the map is outdated, the node answers MOVED <slot> <address> and the client updates its map; during a slot migration, ASK redirects a single request.
• Adding a node = moving some slots to it, live, without rehashing every key.

flowchart LR
    C["cluster-aware client<br/>slot map cached"] -->|"event:42 → slot 16271"| N3
    C -->|"prices:42 → slot 9049"| N2
    N1[("primary A<br/>slots 0–5460")] --- R1[("replica A")]
    N2[("primary B<br/>slots 5461–10922")] --- R2[("replica B")]
    N3[("primary C<br/>slots 10923–16383")] --- R3[("replica C")]

> CLUSTER KEYSLOT event:42
(integer) 16271
> CLUSTER KEYSLOT prices:42
(integer) 9049
> CLUSTER KEYSLOT {event:42}:seats
(integer) 16271
> CLUSTER KEYSLOT {event:42}:prices
(integer) 16271

Multi-key operations (MGET, MULTI/EXEC, Lua scripts touching several keys) only work when all keys are in the same slot — otherwise Redis answers CROSSSLOT. Hash tags solve this: if a key contains {...}, only the part inside the braces is hashed. {event:42}:seats and {event:42}:prices land in the same slot, so a script can update both atomically.

Hash slots vs. consistent hashing

Memcached takes a different approach: the servers do not know about each other, and the client decides which server holds a key, usually with consistent hashing (the ketama algorithm) so that adding a server remaps only ~1/N of the keys (Databases — consistent hashing). Redis Cluster uses a fixed number of slots instead: the mapping key → slot never changes, only slot → node does, and the nodes themselves coordinate failover and redirects.

Managed Redis

Managed services take care of failover, patching and backups; you still own sizing, eviction policy, key design, timeouts and what happens when it fails.

Sizing a Redis deployment

Connecting from Spring Boot

The configuration used in Hands-on 5:

spring:
  data:
    redis:
      host: ${REDIS_HOST:redis}
      port: 6379
      timeout: 50ms            # command timeout: fail fast if Redis is slow
      connect-timeout: 200ms
      # cluster:
      #   nodes: redis-0:6379,redis-1:6379,redis-2:6379
  cache:
    type: redis
    redis:
      time-to-live: 5m         # default TTL for @Cacheable caches
      cache-null-values: false
      key-prefix: "boxoffice:catalog:"

services:
  redis:
    image: redis:8-alpine
    command: ["redis-server", "--maxmemory", "256mb", "--maxmemory-policy", "allkeys-lru"]
    ports:
      - "6379:6379"

How it connects

flowchart LR
    FAST["in memory,<br/>one command at a time"] --> DS["data structures: strings,<br/>hashes, sorted sets, streams"]
    DS --> WR["sorted set =<br/>waiting room → Messaging"]
    DS --> SESS["hashes = sessions,<br/>strings = cached JSON"]
    FAST --> ATOM["atomicity: single commands,<br/>MULTI, Lua"]
    ATOM --> RL["rate-limit counters<br/>→ Edge API gateway"]
    ATOM --> PRE["seat pre-hold in Redis,<br/>SQL still decides → Databases"]
    FAST --> PERS["persistence: RDB, AOF"]
    FAST --> REP["asynchronous replication,<br/>failover"]
    REP --> CL["Redis Cluster<br/>16,384 hash slots"]
    CL -.-> CH["vs consistent hashing<br/>→ Partitioning"]

Palette components: cache (Redis or Valkey, managed or self-run) · queue (a sorted-set waiting room; lists as simple job queues) · stream (Redis Streams, a lightweight event log) · apigw (rate-limit counters with INCR + EXPIRE) · sql (still decides the seat hold) · app (Spring Boot clients with pools and timeouts). Scenarios: read-heavy-cache, flash-sale, rate-limiter. Continues in: Databases — consistent hashing, Databases — replication, Edge — token bucket, Case study: distributed cache, Hands-on 5.