10. Unique ID Generation
1
The picture to keep in your head2
10.1 What makes a good ID?3
10.2 What's wrong with auto-increment?4
10.3 Why does auto-increment break across many servers?5
10.4 What are UUIDs, and which version should you use?6
10.5 How do Snowflake IDs work?7
10.6 What are ticket servers and ID ranges?8
10.7 Why does clock skew matter for time-based IDs?9
10.8 How do you make short IDs with base62?10
10.9 Should IDs be guessable or unguessable?11
Memory card and where the analogy breaks12
Practice: five levels13
Interview questions14
Solutions15
Sources16
Code lab10. Unique ID Generation
10.3 Why does auto-increment break across many servers?
3 min read+10 XP
At the bank: Twenty machines all start at 1. Head office receives twenty "token 57"s and can't tell them apart. The obvious fix, one central machine for every branch, means every customer in the country waits on one machine.
In the system: Two ways it goes wrong.
Figure: each shard's counter is unique on its own. Across shards, "order 1003" means two different orders.
- Each database counts on its own. After sharding, shard A and shard B both create order 1003. Any feature that looks across shards (search, analytics, customer support, merging data) now has duplicate IDs.
- One shared counter becomes a bottleneck. If every app server asks one database for the next number, that database is in the path of every write, and if it's down, nobody can create anything.
You also often want to know an ID before the row is saved: to put it on a queue message, return it to the client, or link related rows. Database auto-increment only tells you after the insert.
So distributed systems use one of three families: random IDs (10.4), structured time-based IDs (10.5), or coordinated ranges (10.6).
Memory code: "Many counters repeat; one counter queues."