STANDARDwalkthrough
Ticket Servers and Range Allocation
Before Snowflake, Flickr solved unique IDs with a ticket server: a MySQL box whose only job was REPLACE INTO a one-row table and return LAST_INSERT_ID. Every ID minted meant one round trip to that box.
The shape: a central allocator hands out ranges instead of single values. A worker requests "give me 10,000 IDs", the allocator atomically advances a counter from N to N+10,000, and the worker mints locally from its range with zero coordination until it runs dry: then fetches the next range.
“It worked: and its descendants still work: because the idea generalizes into range allocation, the pattern our URL shortener (topic 1) used for counter blocks.”
Coordination cost drops from per-ID to per-range: one database write per 10,000 IDs is nothing. The trade-offs versus Snowflake are crisp and worth saying as a table.
Ranges give strictly dense, gap-light IDs (marketing loves invoice-number-style sequences) and need no clock discipline at all: no NTP, no backward-step policy. Snowflake gives time-ordering (ranges do not: a worker draining yesterday's range mints lower IDs than a fresh worker) and no central dependency even off the hot path.
Ranges lose IDs on crash (a worker that dies with 9,000 unused IDs strands them: gaps, usually acceptable); Snowflake loses nothing but demands clock and worker-ID hygiene. Availability: the allocator is a single point of failure for new range grants only: workers with unspent ranges keep minting through an allocator outage, and Flickr famously ran two ticket servers (one issuing odd, one even) for redundancy.
When to choose which: ranges when you want density, simplicity, or already have the pattern (our url-shortener's 62^7 code blocks ARE this); Snowflake when you want time-ordering and zero central infrastructure. What if the interviewer asks: can you combine them?
Yes: allocate WORKER IDS by range lease and mint Snowflake IDs locally: which is exactly what the ZooKeeper assignment scheme is.
Related concepts