Art of Codeartofcode
Lesson 6 of 16

10. Unique ID Generation

1
The picture to keep in your head
2
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 breaks
12
Practice: five levels
13
Interview questions
14
Solutions
15
Sources
16
Code lab
10. Unique ID Generation

10.5 How do Snowflake IDs work?

3 min read+10 XP

At the bank: Each token is stamped: the time, the branch number, and a count within that minute: "0930-B4-017". No two branches share a branch number, and each branch never repeats a count within the same minute, so no two tokens can ever match, with no phone call to head office.

In the system: Twitter introduced Snowflake in 2010 for exactly this: unique 64-bit IDs, roughly sorted by time, generated by many machines without coordinating on each ID. The classic layout:

| 1 bit unused | 41 bits: milliseconds since a chosen epoch | 10 bits: machine | 12 bits: sequence |
  • Timestamp (41 bits): milliseconds since your own starting date (the epoch). 2⁴¹ milliseconds is about 69.7 years of IDs.
  • Machine ID (10 bits): up to 1,024 generators. Each must have a different number (assigned by config or by a coordinator at startup).
  • Sequence (12 bits): a counter for IDs made in the same millisecond on the same machine: up to 4,096 per millisecond, so over 4 million IDs a second per machine. If it runs out within a millisecond, the generator waits for the next one.

Why it's popular:

  • Fits in a 64-bit integer (BIGINT): small, fast, and sorts by time.
  • No round trip to anything when creating an ID.
  • You can decode an ID to see when and where it was made, which helps debugging.

Variations are common. Instagram's well-known scheme (2012) used 41 bits of time, 13 bits of shard ID and 10 bits of sequence, generated inside each PostgreSQL shard, so an ID also tells you which shard holds the row.

The cost: Snowflake IDs trust the clock (10.7) and need machine IDs managed so no two generators share one.

Memory code: "Time, machine, count: stamp all three and nothing can clash."