Step 1: System Definition

On a single database, an identifier costs nothing: the table keeps a counter, and every new row takes the next number. Run the same code on fifty servers in four regions, and the guarantee disappears, because each server counts independently and two of them will eventually hand out the same number. This case study designs the service that prevents that.

A Globally Unique Identifier (GUID) generation system issues identifiers that are unique across every caller, server, and region, at hundreds of thousands per second. Callers use them as database primary keys, event and message IDs, and handles for stored objects.

The system offers two formats. An opaque ID is a random value, like a UUID, that carries no order and reveals nothing about when or where it was made. An ordered ID encodes time, so a newer ID is larger than an older one and sorting by ID roughly follows creation order.

"Globally unique" means that an ID made on any node, at any time, differs from every ID the system has ever issued, including retries. That rule is never relaxed. "At scale" means hundreds of thousands of requests per second from many services in many regions, which rules out any design where every request waits on one machine. The diagram below shows the main entities and the request flow.

Four existing approaches frame the design.

UUID (Universally Unique Identifier). A 128-bit value, which Microsoft calls a GUID. Version 4 fills 122 of those bits with random data and uses the remaining 6 to mark the version. A generator checks nothing before returning a UUIDv4, because a collision is too unlikely to guard against: producing one billion every second for about 86 years gives only a 50 percent chance of a single duplicate. UUIDs need no coordination, but they are twice the size of a 64-bit integer and do not sort by creation time.

Snowflake ID. A 64-bit ordered format that Twitter built for tweet IDs. It packs a timestamp, a machine number, and a sequence counter into one integer, and the timestamp in the high bits makes the IDs sort by creation time. Instagram and Discord use variants of the same layout.

ULID and KSUID. Newer formats that combine a timestamp with random bits, 128 bits for ULID and 160 for KSUID. They sort correctly as strings and need no coordination.

Database auto-increment keys. A database numbers the rows of one table in order, which is unique and perfectly sorted on one machine. Across many databases or shards (pieces of one database spread over several machines), a single shared counter becomes a bottleneck: every request updates the same row, and one failure stops every insert. Separate counters per shard produce duplicates unless each shard receives its own pre-assigned range.

A sequence is monotonic when every later value is higher than every earlier one. A single generator can promise that for its own output, but a fleet of generators reading separate clocks cannot promise it globally. Per-generator monotonic order is the strongest ordering guarantee this design makes.

An online store shows why one system needs both formats. Its order table uses sortable IDs as primary keys, so recent orders sit together in the index. The receipt link it emails to the customer uses an opaque ID instead. A sortable ID in that link would reveal roughly how many orders the store takes per hour, and a customer could try neighboring values to find other people's receipts.

Web servers, microservices, and devices labeling sensor readings share the store's need: many independent processes must label things at once, without colliding or waiting on a central bottleneck.