Approach 5: Twitter Snowflake

In one line: Snowflake is the design people actually deploy, and its bit layout is the most commonly asked detail in this entire topic. Being able to allocate the 64 bits and justify each field is the deliverable.

The bit layout

Time first is what makes the ID sortable: comparing two IDs numerically compares their timestamps before anything else.

 1 bit    41 bits              10 bits      12 bits
[sign]   [timestamp ms]       [worker]     [sequence]
   0     0010100100...           1010      000000000001

 1 + 41 + 10 + 12 = 64 bits

Each field answers one of the previous lesson's failures. The sequence fixes same-millisecond collisions on one server. The worker fixes cross-server collisions. The timestamp provides ordering. The sign bit just keeps the number positive so it sorts correctly as a signed integer.

The epoch

Snowflake uses a default epoch of 1288834974657 (Nov 4, 2010), but systems can define a custom epoch — for instance Jan 1, 2022.

Time to range depletion = 2^41 identifiers
                        / (365 * 24 * 60 * 60 * 1000 identifiers/sec)
                        ~= 69 years

This 41-bit range allows for 69 years of IDs.

Decoding a real Snowflake ID

Worth walking end to end, because it makes the layout concrete:

Step 1 — read the 41 timestamp bits as a decimal:
         352,721,356,343

Step 2 — add the Twitter epoch:
         352,721,356,343 + 1,288,834,974,657 = 1,641,556,331,000

Step 3 — interpret as milliseconds since the UNIX epoch:
         1,641,556,331,000 ms  ->  Jan 07 2022 11:52:11 UTC

The timestamp field is a delta from the epoch, not an absolute UNIX time — which is exactly why the epoch choice matters and why two systems with different epochs produce incomparable IDs.

Pros and cons

That second point is subtle and worth stating: the timestamp budget drains on a wall clock, not on usage. A system generating ten IDs a day exhausts its 41 bits at exactly the same moment as one generating billions.

The deeper weakness: physical clocks are unreliable

Clock error can be as high as 17 seconds per day. On a single server that does not matter — every transaction lands on the same machine, so the ordering is internally consistent. In a distributed environment the clocks won't remain synced, and no matter how often you synchronize, there will always be skew between the clocks in the system.

The concrete failure: if a server's clock drifts forward, it generates IDs for a future time. When NTP recalibrates the clock backwards, the server may generate duplicate timestamps or violate causality — reissuing a millisecond it has already used.

NTP synchronizes clocks over variable-latency networks, aiming to keep computers within milliseconds of UTC, but it is susceptible to network latency and security issues. Even with high-resolution clocks, the risk persists — which is why Snowflake scores only weak on causality.

What if a worker exceeds 4,096 IDs in one millisecond?

The sequence field wraps. The standard behavior is to wait until the next millisecond before issuing more — the generator blocks briefly rather than reusing a sequence number.

That is the right trade: a sub-millisecond stall is preferable to a duplicate ID. If a single worker genuinely needs more than 4 million IDs per second sustained, the answer is more workers, not more sequence bits — you have 1,024 of them available.

Where does a worker get its ID?

The ten worker bits assume every generator already knows a number nobody else is using. The design does not say how, and that omission is the most common Snowflake failure in practice — because the failure mode is silent.

Four ways to assign the number, and they are not equivalent:

The property that makes the coordination-service answer acceptable is worth stating: the coordination happens once, at startup, not per ID. That is the same "amortize the coordination" move as the range handler earlier in the chapter — pay a coordinated cost rarely, then run free.

When the clock goes backwards

The chapter has established that clocks drift and NTP corrects them. The practical question is what a running generator does at the moment it notices, and it needs a decided answer rather than an assumption.

The first option is the one to name and reject: issuing anyway is how Snowflake produces duplicates, and it does so silently.

Between the other two, the practical rule is by magnitude. A small rollback — a few milliseconds, ordinary NTP correction — is best handled by waiting, since the stall is shorter than any alternative. A large rollback, seconds or more, means something is genuinely wrong with that machine, and the right move is to refuse to issue and fail loudly rather than block for seconds while pretending to be healthy.

Both are better than the option candidates usually reach for, which is to keep a monotonic counter and ignore the clock — because that quietly turns a time-sortable ID into a not-quite-time-sortable one, and nothing tells you it happened.

The general principle: a system that derives correctness from the clock needs an explicit answer for the clock being wrong. "We assume NTP keeps it accurate" is an assumption, not a design.

Scorecard

Four solid columns and a weak on causality — because the ordering it provides is only as good as the clocks producing it.

Interview signal by level

Next: ordering without trusting clocks at all.