Design a unique ID generator

An id generator hands out the numbers that name orders, users and messages. Here about 300 services in three regions need about 2 million a second at peak, and the ids become primary keys, event keys, parts of URLs and receipt numbers. A repeated id merges two customers’ orders, so uniqueness is the invariant.

It is hard because no central counter can serve that from three regions within a millisecond, clocks step back, instances start and stop 50,000 times a day, and 64 bits leave little room. This page builds the classic answer, the time plus a machine number plus a counter, as in Twitter’s Snowflake of 2010 (Snowflake README (opens in a new tab)), and credits blocks, ticket servers and UUIDs where they fit.

The practice brief gives the requirements; confirm them quickly. The first non-functional one is the invariant: no two entities ever get the same id, across services, regions, restarts and clock problems.

Work out the few numbers the id depends on. The volume is not the limit; the instances and the years are.

An id is one signed 64-bit number, read from the left as in the table. The top bit stays 0, so the id is positive in Java and in a signed BIGINT; 41 bits of milliseconds since a custom epoch of 1 January 2026 last to 2095; the rest name the region and the generator, and count ids within the millisecond, with 256 a millisecond, five times the busiest instance’s need.

A generator keeps three values in memory: its number, the last millisecond it used and the counter within it. When the counter fills within one millisecond, it waits for the next, at most a millisecond’s delay. Store the id as a BIGINT: 8 bytes a key, half a UUID. Don’t copy a published split without checking it; the first Keep reading note below shows why.

Most services link the generator in: next() returns one id and next(n) a batch, as 64-bit integers. Services that can’t embed it call a small service in their own region. decode(id) returns when an id was made, its region and its generator.

Outside the backend, ids travel as strings, such as "id": "98418505016149763". JavaScript numbers hold integers exactly only up to 2⁵³ − 1 (MDN (opens in a new tab)), so that id parsed as a number becomes 98418505016149760, a different order. A generator that can’t issue returns an error the caller retries elsewhere.

Build the design in three steps: keep generators apart, keep the network out of the path, and put time first.