2M/s
IDs a second at the festival-sale peak
Assume 40 billion IDs a day, about 463k a second on average. Midnight at a sale or a cricket final’s last over pushes about 4× that.
Who hands out the next ID?
Bad: One shared counter
One primary writes every ID: one machine’s ceiling, one point of failure.
Good: Built from unique parts
Time, generator number, counter: built in memory, no call to anyone.
63 bits: time first, then who minted it, then a counter
Time first, so IDs sort by when they were made. Each live generator owns its number, so two can never collide.
A paused pod wakes still minting as worker 37. Its lease went to another pod.
The trick
Fence with the ID’s own timestamp: the old owner stamps only before valid_until, the new one only after.
Rising IDs: cheap in a B-tree, hot in Spanner
Range-partitioned stores send every insert to the newest range, so one server takes 1M writes a second. Prefix the key with hash(id) % 64 and writes spread.
The time daemon steps the clock back 25 ms. Now what?
Trust it and the generator re-issues IDs for 25 ms it already used, usually with no error anywhere.
A clock that never goes back
- Use max(wall clock, last timestamp)
- Borrow at most 1 s ahead, then fail
- After a restart, start above the old
valid_until - Slew, never step; alert on backward jumps
Remember
Snowflake-style 64-bit IDs from memory. Time first so they sort, time-fenced worker leases so they never collide, and a clock that never goes back.