redis

notes on redis — the protocol, the data types, the operational patterns that show up when you actually build on it.

written from the building side: redis (a 0.16 zig client), burner-redis (an in-process redis-compat engine), and docket (a distributed-task system that lives on top of streams + Lua).

topics

• streams — XADD / XREADGROUP / XACK / PEL / XAUTOCLAIM, consumer groups as the horizontal-scale primitive
• eval-lua — atomic scripts, redis.call / redis.pcall, why it's Lua 5.1 forever
• embedded — the burner-redis pattern: run the whole thing in-process for tests and self-hosted deployments

what redis actually is

a single-threaded, in-memory key-value store with rich typed values (strings, hashes, sets, sorted sets, streams, lists). every command is atomic because there's no concurrent mutation. you compose larger atomic operations by writing Lua scripts and submitting them via EVAL — the whole script runs without anyone else touching keys.

the wire protocol is RESP — a simple line-oriented binary-ish format. four types matter in practice:

• simple string: +OK\r\n
• bulk string: $5\r\nhello\r\n (binary-safe; what you get for actual values)
• integer: :42\r\n
• array: *3\r\n... (used everywhere — multi-key replies, EVAL returns, XREADGROUP output)

a redis client is basically a RESP encoder/decoder bolted to a single TCP connection. the hard parts are the memory model (slices into the read buffer, when to copy, when to arena) and the type-specific parsing (XREADGROUP reply has four levels of nested arrays).

the operational model

• one connection per worker (no thread safety on a single client)
• pipelining is "send N commands, read N replies" — not request/response
• pub/sub turns the connection into a subscriber socket — you can't do regular commands on it anymore
• persistence is RDB (point-in-time snapshot) + AOF (append-only command log). for embedded use you can swap to MessagePack or skip persistence entirely.