From one box to a fleet: 1 → 1000+ scaling.

Pinterest’s growth through 2011 was explosive. The fleet started small — eight EC2 servers running one MySQL instance each — and the engineering account is blunt about where that ended: by September 2011, “every piece of our infrastructure was over capacity.”

The answer they shipped was a sharded fleet. They finished launching the sharding approach “in early 2012, and it’s still the system we use today,” and it carried 50 billion Pins across one billion boards. The title of this dive is that arc — one box to a fleet — and the lesson is not the size of the fleet but what made it reachable: a scheme where adding capacity does not mean moving the data already stored.

Pinterest stated the principle that governed every capacity move: “We hated moving data around, especially item by item… If we had to move data, it was better to move an entire virtual node to a different physical node.” Capacity is added by upgrading a machine, opening a new shard range, or migrating a whole virtual node — never by re-distributing rows one at a time. A migration that touches every item does not scale; one that relocates a whole bucket does.

PinLater, Pinterest’s asynchronous job system, made “add a shard” trivial by putting the shard id where it could never need a lookup: inside the job’s own descriptor. The descriptor format, verbatim from the project’s documentation:

Shards live within a queue. PinLater uses a free sharding scheme — a shard is chosen when a job is enqueued — and the chosen shard is then carried in the descriptor for the life of the job. Two consequences follow directly.

This is the same scaling posture at the queue layer that the sharded fleet gives at the database layer: the placement decision is made once, written into the identity, and never revisited. PinLater ran it at real scale — “more than 500 job queues processing north of six million jobs per minute” on “more than 10 different clusters all on Amazon EC2.”

The echo bus reaches the same “add a shard without moving data” property by a different mechanism, and the mechanism is the one the cluster specification defines. Every key of one queue is built with a hashtag, and the slot it lands on is computed client-side from that hashtag:

EchoMQ.Keyspace.slot/1 computes a key’s cluster slot as rem(crc16(hashtag(key), 0), 16384) — CRC16-XMODEM over the substring inside the first {...}, modulo 16384, exactly the cluster specification’s algorithm. The module’s own words: “every key of one queue lands on one slot.” A known vector pins the behaviour: slot("123456789") == 12739.

The scaling payoff is the same as PinLater’s free sharding. A queue’s slot is a pure function of the queue name — it is computed, never looked up, and it never changes. When the cluster grows from a few nodes to many, slots are reassigned to nodes, but a queue’s keys stay together on whatever node now owns their slot. No key is re-homed by name; the slot was decided the moment the queue was named. Pinterest decides placement at enqueue and writes it into the descriptor; the bus decides placement from the name and computes it on every call. Both make growth a matter of widening the set, not relocating the contents.

The scale figures hide a second lesson, and PinLater states it as a turn. PinLater shipped with two storage backends, MySQL and Redis, and the guidance was throughput-driven: services should “default to use the MySQL backend as long as the QPS is in the lower to mid range (no more than 1000 QPS per shard). If the QPS is expected to be higher than this, then the Redis implementation should be used.” Redis was the high-throughput backend.

Then the trade reversed. Pinterest reported “5X more throughput on the MySQL backend, which allows us to do over 2,000 enqueues per second with a single i2.2xl MySQL EC2 instance” and so chose to “move all our workloads to MySQL and deprecate the use of the Redis backend” — for MySQL’s durability and replication. A list-in-RAM queue is fast, but a job store that must not lose work eventually wants a durable record of every job. This is the tension R7.01 (Redis as a primary database) names directly, and it is the reason the persistence floor exists.

The BCS stack answers the same tension not by replacing the engine but with a durability dial. The job is a HASH held in Valkey, and that HASH is the record of truth: the enqueue script writes HSET KEYS[1] 'state' 'pending' 'attempts' '0' 'payload' …, and state, attempts, and payload carry the job’s whole life. That record lives in RAM for speed, the way PinLater’s Redis backend did. Where it is made durable is the dial — ETS, then Valkey, then a committed engine behind it — the subject of /echo-persistence. PinLater moved a layer to gain durability; the BCS stack keeps one record of truth and turns the durability up underneath it.

One box to a fleet is one idea repeated at two layers. Pinterest went from eight servers to a sharded fleet of fifty billion Pins by deciding placement up front — the shard in the Pin’s id, the shard in PinLater’s job descriptor — so a new shard is configuration, never a migration. The echo bus does the same with the {q} hashtag: a queue’s slot is a function of its name, computed client-side, fixed for the life of the queue, so the cluster grows without re-homing a key. And PinLater’s Redis → MySQL durability turn is the same ceiling the persistence floor answers with a dial. The next page is the chapter landing — R8 continues to the Twitter/X case study (R8.04, specified) and the production capstone.