Section 7: Five Doors, One Key - Deep Dive: Five Ways to Mint an ID

Executive Summary: Section 6 put a Snowflake-style generator on the board without defending the choice. This section defends it. We walk five ways to mint an ID: database auto-increment, a Flickr-style ticket server, UUIDv4 and UUIDv7, range leasing, and Snowflake. Each gets its mechanism, the number that judges it, its trade-off, and the condition under which it would win. The deciding constraints are the ones Section 1 surfaced: 64 bits and ordering within about a second, at 1 million IDs/s peak across five regions. We also say the honest thing out loud. If 128-bit keys were acceptable, UUIDv7 generated inside each caller would win, and there would be no service to design.

The interviewer taps the box labelled "generator". "You drew Snowflake before you justified it. Convince me. What else did you consider?"

This is the moment the problem is really about. A weak answer recites "Twitter uses Snowflake." A strong one lays out the field and lets the constraints do the eliminating. You say: "Five candidates. I'll score each against the three constraints from Section 1: unique forever, fits a signed 64-bit BIGINT, and sorts by creation time within about a second. Then a fourth that matters at our scale: how much coordination each ID costs."

Candidate One: Database Auto-Increment

Mechanism. One database owns a counter. Every insert gets the next integer.

Why it's tempting. It's 64-bit, perfectly ordered, gap-light, and every engineer already understands it.

Why it fails here. Every ID in the company becomes a write to one row on one primary. At 1 million IDs/s peak, that is a single machine serialising every new post, message, order and payment in five regions. Four of those regions pay a cross-region round trip per ID, which blows Section 2's p99 ≤ 2 ms budget before the database does any work. And the primary is a single point of failure for every write path in the company. Failover to a replica that lagged by even a few increments hands out IDs that were already issued.

Flip trigger. One service, one database, modest volume. Inside a single table, auto-increment is still the right default. It just can't be a company-wide authority.