What became core: a technique, not a donation.

It is tempting to say Twitter contributed quicklist. That is wrong, and the encoding’s author says so directly: “Twitter started doing this years ago to store everybody’s timelines, but for various reasons they haven’t contributed their implementation back to the world.”

The honest version has three parts:

1. The technique was internal at Twitter and elsewhere. Storing lists as ziplists inside a linked list was a known scale technique, used to hold timelines affordably. It lived in private codebases.
2. It became core Redis as a separate, independent implementation. Quicklist shipped in Redis 3.2, authored by Matt Stancliff (redis/redis PR #2143) — written from the idea, not from Twitter’s source.
3. Twitter’s own code was never upstreamed. The implementation that ran Twitter’s timelines did not become the core feature; the core feature was re-built in the open.

So the lesson is a scale-driven internal technique becoming a core encoding — not a corporate code donation. A pattern proven privately at scale was independently implemented as a primitive everyone ships. The credit for the core feature is the implementer’s; the motivation came from a problem several large deployments had already solved in private.

Quicklist did not stop at ziplists. The node encoding evolved.

A ziplist was the original packed block — compact, but with a known sensitivity to cascading updates: changing one entry’s size could ripple through the encoding of following entries. The listpack was introduced to replace it, removing that cascade and simplifying the format. In Redis 7.0 the listpack became the node encoding for lists, so a modern quicklist is a doubly-linked list of listpacks, not of ziplists.

The shape is unchanged — a linked list of packed nodes — but the packed node is now a listpack. That is why this course says “ziplists/listpacks” when describing a quicklist node: the original is the ziplist, today’s is the listpack, and the principle is identical. Small lists are stored as a single packed node directly; only when a list grows past the node-size threshold does it become a multi-node quicklist. Those thresholds — the subject of R7.02 — are what decide when a single listpack becomes a quicklist of many.

EchoMQ writes to Valkey lists, so it gets the modern encoding without asking. There is no setting to turn quicklist on and no code that chooses it; it is the list encoding, and all Valkey lists are quicklists. The lane ring and the wake list are native Redis lists:

Each of these runs on a quicklist whose nodes are listpacks. The wake list, capped at 64, is a single listpack node; the ring holds the lanes serviceable right now and is short by construction. EchoMQ inherits, at no cost, the encoding that Twitter’s scale drove into core Redis a decade ago.

The honest framing carries through to the end: the credit is Matt Stancliff’s, the motivation was a problem Twitter and others had at scale, and EchoMQ’s gain is only that the primitive is in the engine. The worked consumer, codemojex, never sees the encoding — it mints a branded JOB with EchoData.BrandedId.generate!(“JOB”) and enqueues it onto a lane, and the list it lands in is a quicklist because every Valkey list is.

Quicklist’s story is precise: the technique of packing ziplists into a linked list was used internally at Twitter and never upstreamed; the core feature was written independently by Matt Stancliff and shipped in Redis 3.2 (PR #2143); the node encoding later became the listpack in 7.0. A pattern proven privately at scale became a primitive everyone ships. EchoMQ inherits it for free — all Valkey lists are quicklists — and the only thing the bus controls is keeping the wake list short enough to stay one node. The chapter continues to R8.05, where Uber’s resilience techniques meet the connector’s recovery behaviour.