Why a Sequencer
Why this matters: "generate an ID" sounds like the least interesting part of any system. It is actually a distributed-systems problem in miniature — uniqueness, ordering, availability, and coordination cost, all in 64 bits.
Key takeaway
Large distributed systems process millions of events per second — posts, transactions — and each needs a globally unique identifier. Single-node databases use auto-increment columns, but that does not scale when multiple nodes generate identifiers independently.
The problem with auto-increment
A single database hands out 1, 2, 3, 4 and uniqueness is trivial because one thing decides. Distributed environments — including horizontally sharded tables — have no such thing, and require a coordinated or decentralized strategy.
That question — who decides — is the whole chapter. Every approach that follows is a different answer: coordinate through a shared database, hand out ranges, or avoid coordination entirely by making collisions improbable or structurally impossible.
The two jobs an ID does
Primary keys. These identifiers typically serve as primary keys in storage systems, which is why their size and format matter — a wide, non-numeric key slows indexing and inserts on every write.
Debugging and tracing. Unique IDs make it possible to follow one request across a fleet. Facebook's Canopy uses a TraceID to track events across the hundreds of microservices involved in a single user request.
Why time-sortable IDs
Beyond uniqueness, there is a strong reason to want IDs that sort by time:
| Benefit | Why it follows from time-sortability |
|---|---|
| Free chronological ordering | Sorting by primary key sorts by creation time — no separate timestamp column or index needed |
| Efficient range queries | "Everything from last Tuesday" becomes a contiguous key range rather than a scan |
| Better index locality | Recent inserts cluster together in the B-tree instead of scattering across it |
| Conflict resolution | A key-value store can use time-ordered IDs to implement last-write-wins |
| Debuggability | You can read an ID and know roughly when the event happened |
How this chapter is organized
Part 1 defines the requirements and compares three generation methods that solve uniqueness. Part 2 incorporates time to handle causality, and revisits every approach against the same scorecard.
Key takeaway
An ID generator has to answer "who decides?" without a single decider. The approaches differ in how much coordination they require — and coordination is the thing that costs availability and throughput.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "We'd use a UUID or an auto-increment ID." |
| L5 | Sees the distributed problem: "auto-increment needs one authority, which doesn't exist across shards — so either coordinate or make collisions improbable." |
| Staff+ | Frames the real trade: "this is a coordination problem in 64 bits. And I'd ask whether we need time-sortability, because it buys range queries and index locality but creates a write hotspot on the newest shard." |
Next: pinning down the requirements.