The city of Stone Seal sat halfway up the mountain. It was small, but it held the only seal bureau on the whole trade road.

The rule was nine generations old: every document filed in the city — deeds, grain ledgers, pleadings, a craftsman’s IOU — had to carry a numbered seal stamped in its upper right corner. The numbers could not repeat. If they did, the clerks at the Heaven’s Pivot Archive would slide two different sheets into the same pigeonhole, and a year later a man asking for his land deed would pull out a stranger’s debt.

For a long time this was not hard. Nine seal workshops kept nine separate ledgers: one, two, three, up to a few hundred, then a new book. Documents circulated inside the city and never crossed between workshops. Nine ledgers that never met never quarrelled.

Then the mountain road opened, three downstream counties were absorbed, and everything changed.

A single document might be drafted in the east shop, sealed again in the west, and filed back in the south. A grain ledger was split into five parts and copied simultaneously by five shops. That spring the archive had its incident: the east shop’s number one thousand seven and the west shop’s number one thousand seven entered the archive on the same day. Two sheets, one number. The clerk filed a land deed into the grain drawer.

Three months later the Liu family lost thirty irrigated acres.

— —

The head of the seal bureau was named Shen Yan.

He did not rush to replace the ledgers. He went to look at the bell tower.

The tower stood at the city’s centre. Once every hao-ke — a hair-flick of time, too short for the ear to catch its echo, more than eight hundred thousand of them in a day — the bell-keeper struck the bell. And the tower’s count was continuous: the number of the strike was the number of the hao-ke. There was only one tower in the city, so the count everyone heard was always the same count.

Shen Yan stood beneath that tower for a full day, and came away with a new seal.

Pressed once, the new seal left three segments on the page:

The first: which strike of the bell the tower had just rung. The second: the workshop’s guild number. The third: how many seals this workshop had already pressed within that one strike.

The guild number was fixed. Every workshop registered with the guild registry and drew a number between zero and one thousand twenty-three, held for life, never repeated.

So two shops sealing at the same instant shared the first segment (same strike) and might share the third (both pressing their first seal of that strike), but never the second — and thus never the whole number.

And one shop pressing twice in a row produced a different third segment — also never the whole number.

The day he handed the sample to the registry, Shen Yan said eight words: Ask no one. Each makes its own.

— —

The seal worked, and the trouble came anyway, in four shapes.

The first was four thousand.

The third segment held twelve places, zero through four thousand ninety-five. Within a single bell strike, one workshop could press at most four thousand ninety-five seals.

That autumn’s tax season, the line outside the east shop delivered six thousand sheets inside one strike. The sealers had to lift their brushes and simply wait for the next strike before pressing again. It was a hard wait — not a broken brush, but an exhausted number.

Shen Yan wrote on the wall: one strike, four thousand seals; when it fills, wait for the next.

The second was a backward bell.

At the winter solstice, the bell-keeper’s apprentice calibrated the water clock and turned the bell back by a single notch.

Inside that notch the tower sang its old count again. The workshops did not know, and pressed as usual — same bell, same guild number, same ordinal. The seal that came out was identical to one pressed half an hour earlier.

Two documents, one number. This time the fault was not the ledger. It was the bell.

Shen Yan set a second rule: each workshop must remember the first segment of its last seal. If the tower’s count was not greater than the previous one, the brush must not fall — either wait until the count truly passes, or go to the registry and take a new guild number to begin again. Stop the press rather than repeat a number.

The third was the guild number itself.

The registry had kept a single roll: whoever came to register received the next number. Then fire took half the north district, and the roll with it. Two clerks rebuilt it, each copying a version, each dispensing numbers. And so two workshops both held four hundred seventeen.

Both were perfectly obedient. But no rule reaches into another man’s guild number.

Only then did Shen Yan understand the premise hidden inside his eight words: guild numbers never repeat. That was not something a seal bureau could guarantee. It had to be guaranteed by whoever dispensed them — one number, at any moment, with exactly one living holder.

The fourth was the horizon.

The first segment had only forty-one places. Counted in hao-ke, that was sixty-nine years.

After sixty-nine years the tower’s count would reach its ceiling and could not roll over. There was no remedy for this. It could only be carved into the wall, so the next generation would know the date.

— —

The new seal served for seventeen years and the archive never saw a repeat.

The clerks discovered a convenience along the way: read the whole seal as a single number, and its size roughly followed the order in which the documents had been pressed. Filing no longer required opening a cabinet in the middle to find a slot — new sheets went onto the end. A whole cabinet of volumes ran straight through, front to back.

That was the fourth benefit of the seal, and Shen Yan had not designed it.

The same year, an old clerk in the south district proposed a different seal: no bell, no guild number — shut your eyes, draw a number from a sack of random digits, and use whatever comes out. That seal would not easily repeat either; the chance of drawing the same number twice was small enough to ignore. But it was long — one hundred twenty-eight marks — and it carried no order at all, so filing meant leafing through page after page to compare.

There was an even simpler scheme: keep one central number office in the city. Whoever wants a number queues at the window and receives the next one. No repeats, and the order would be beautiful. But every sheet in the city would stand in line before a single room; and if that room’s lamp went out, every document in the city stopped at the window.

Shen Yan chose the hardest road: no central window, every sealer issues their own — as long as the guild numbers are settled first, the bell does the rest.

By now you have probably recognized it: this is Snowflake, the most copied design in distributed ID generation.

What it is

Snowflake is a 64-bit ID scheme that Twitter open-sourced in 2010. One ID is one int64, cut into bit fields:

• 1 sign bit: unused, so the value stays positive in a Java long.
• 41 bits of millisecond timestamp: measured from a custom epoch (Twitter used 2010-11-04), enough for roughly 69 years.
• 10 bits of machine number (the worker id): splittable into 5 bits of datacenter and 5 of machine, so at most 1024 nodes.
• 12 bits of sequence: a per-millisecond counter, 0–4095. That is 4096 IDs per node per millisecond, about 4.09 million per second.

Generating one is short: read the current millisecond. If it equals the previous one, increment the sequence; when the sequence fills at 4096, spin until the next millisecond (“one strike, four thousand seals”). If the clock is behind the previous millisecond, a clock rollback has occurred — either refuse to issue, or wait for the clock to catch up. Never keep issuing on a stale millisecond.

The point is that it needs no coordination per ID. Worker ids are assigned in advance; once assigned, 1024 nodes issue independently, never speaking to each other, never colliding. The only thing in the whole design that needs coordination is the worker id itself — usually guaranteed by ZooKeeper, an etcd lease, a Kubernetes StatefulSet ordinal, or cloud instance metadata, so that one number has exactly one living holder at a time.

Why it matters

An auto-increment primary key (AUTO_INCREMENT / SERIAL) concentrates the right to issue numbers in one place. It is simple, ordered, and short — at the cost of serialized writes, awkward cross-shard schemes, duplicate or skipped numbers across failovers, and IDs that leak business volume: consecutive order numbers tell a competitor exactly how much you sold today.

UUIDv4 is the opposite: generated locally, never colliding, but 128 bits and fully random. As an InnoDB primary key, random insertion hurts page splits and cache hit rate together; for the same row count, a random key’s index is measurably larger and its write latency measurably worse than an ordered key’s.

Snowflake sits between them: 64 bits, coordination-free, approximately time-ordered. That approximate ordering is worth a great deal in practice — it makes “sort by ID” nearly equal to “sort by creation time”, so pagination, incremental sync, and time-based archiving all ride on it, without paying a global round trip per ID.

Its failure modes are all in the bit layout, and every one of them has happened in production:

• Clock rollback. NTP correction, live VM migration, host clock drift — all can move the clock backwards, and IDs in the same millisecond repeat. An implementation must refuse service when the clock regresses, not do its best.
• Worker id collision. The most common real incident: two pods receive the same worker id (old and new replicas briefly coexisting during a rolling update, or ids derived from the last octet of an IP), and both issue the same ID in the same millisecond. Worker ids must come from a strongly consistent allocator with leases and liveness checks.
• Bursts above 4096 per millisecond. The sequence exhausts, the process waits, and throughput hits a hard ceiling. That is a design limit, not a bug.
• The 69-year horizon. Once 41 bits of milliseconds are spent, only a new epoch or more bits will do — and old and new IDs no longer sort together.
• “Ordered” across nodes is only approximate. Monotonicity is per node, not global. A few milliseconds of clock skew between machines means a few milliseconds of mismatch with real causal order; treating these IDs as strict event order is a common misreading.

Later designs mostly re-cut the same fields. ULID uses 48 bits of milliseconds plus 80 random bits, trading away worker-id allocation. Sonyflake uses 39 bits of 10-millisecond units, 8 bits of sequence, and 16 bits of machine, stretching the horizon and lowering the per-millisecond ceiling. Instagram moved “segments plus stored procedures” into Postgres, letting the database guarantee uniqueness while sharding supplies throughput.

Metaphor mapping

• The archive’s numbered seal → a globally unique ID
• Nine shops keeping nine separate ledgers → many nodes generating locally, no coordination per ID
• Two documents bearing the same number → an ID collision
• One bell strike per hao-ke → the millisecond timestamp (41 bits)
• A single bell tower in the city → a shared monotonic time source
• Segment one: which strike → the timestamp field
• Segment two: the registry’s guild number → the worker id (10 bits)
• Zero through one thousand twenty-three → the 1024-node ceiling
• Segment three: the ordinal within one strike → the sequence (12 bits)
• “Ask no one. Each makes its own.” → coordination-free local generation
• Four thousand ninety-five to a strike, then wait → sequence exhaustion and spinning to the next millisecond
• The bell turned back one notch → clock rollback
• Remembering the last first segment; no increase, no press → refuse to issue on a regressed clock, preserve monotonicity
• Stop the press rather than repeat a number → uniqueness over availability
• The roll burns; two clerks each dispense numbers → duplicate worker-id assignment
• Two shops both holding four hundred seventeen → worker-id collision: same millisecond, same sequence, same ID
• One number, one living holder at a time → a lease that keeps worker ids unique
• Forty-one places, sixty-nine years → timestamp field exhaustion
• Reading the seal as one number ≈ press order → time-ordered IDs, sequential B+ tree inserts and range scans
• Drawing blind from a sack of random digits → UUIDv4: locally unique, unordered, 128 bits
• A random seal needing one hundred twenty-eight marks → the index bloat of UUID primary keys
• One central number office for the city → a centralized auto-increment sequence, a single bottleneck
• The lamp goes out and the whole city queues → the ID service becomes a single point of failure
• New sheets onto the end; the cabinet runs straight through → ordered keys, sequential writes, range queries