Unique ID Generator: ID Generation Strategies

The diagram shows the layout. Written out in order, a 64-bit ID in binary looks like:

[timestamp: 41 bits][region+machine: 10 bits][seq: 12 bits]

Now put real values in it. Suppose the 41-bit timestamp since the epoch is 101010... (some value). Region ID is 3, which is 00011 in 5 bits. Machine ID is 5, which is 00101 in 5 bits. Sequence is 37, which is 0000 0010 0101 in 12 bits. Joining those bits gives the 64-bit number.

A real example: Snowflake ID 1922298559865028608 is a tweet ID. It breaks down into timestamp, machine, and sequence exactly as documented. Anyone who knows the layout can pull the time and other fields out of the ID. That is why we call this format non-opaque. It still serves ordering and scale well, so we accept what it reveals.

Machine ID coordination. The 10-bit field only works if no two live nodes hold the same value. Something has to guarantee that, so we run a ZooKeeper cluster (or a similar coordinator) that owns the 10-bit machine IDs. When a generator node starts, it creates an ephemeral node in ZooKeeper, like /id-generators/<region>/<machine_id>. An ephemeral node is an entry that disappears when the session that created it ends. ZooKeeper can assign the number, or the node can try IDs in order until one is free. Or the node states its region and asks for a free slot in it. For example, region 1 nodes might use IDs 0 to 31. Because ZooKeeper tracks live ephemeral nodes, two live nodes never hold the same ID.

Notice when the coordinator is involved. It is used once, at startup, and never on the path of a single ID.

When a node dies, its ephemeral entry is removed and its machine ID returns to the pool. Reuse needs care. The dead node no longer generates IDs. So reuse is safe if the new node's clock is at or past the old node's last timestamp. If the new clock is behind, the pair could produce the same ID.

That is why we do not hand the number out again immediately. We hold it back for a short buffer, longer than the clock error we accept, or record the old node's last timestamp. The buffer costs one number out of 1024 and removes the failure. Clock issues are covered next.

If ZooKeeper itself fails, existing nodes keep generating with the IDs they already hold. Nothing changes for them. What stops is starting new nodes or reassigning IDs, until ZooKeeper is back. To limit that, we run ZooKeeper as a 3-node ensemble across servers, and possibly across regions. The generator rarely changes state after startup, so short ZooKeeper outages barely matter.

Clock synchronization and skew. Every Snowflake-like system needs clocks that move forward and stay close to each other. All generator nodes run NTP (Network Time Protocol) daemons to keep clocks accurate to a few milliseconds. Small differences between nodes only mean that one node's IDs may look slightly out of order against another's. They never cause duplicates.

The real risk is a clock that jumps backward. An NTP correction or a paused VM can do that. Suppose node A's clock goes back 100 ms. Its timestamps now repeat a range it has already used, with the same machine ID and a reset sequence. That is exactly how a duplicate ID is made. To prevent it:

• Each node remembers the last timestamp it used. If the current time is earlier than that, the generator pauses until the clock passes it again. For small skews the pause is short. For a large jump, the node is stalled for that long, and an operator alert may be needed. Either way, it never issues an ID that could repeat an old one.
• Large backward jumps are rare when NTP is set to adjust in small steps. If one does happen, say someone reset the clock by hand, the safe move is to take the node out of service and restart it with a new machine ID. The node then starts a fresh timeline that cannot overlap its past.
• The last timestamp lives only in memory. A restart erases it, so a restarted node with a slipped clock could reuse a millisecond. We could save the last timestamp to disk on shutdown and refuse to start if the clock is behind it. Since we prefer stateless nodes, a runtime check plus the reuse buffer above is enough for us.
• A clock that jumps forward is less dangerous. The IDs get large timestamps, but they are still unique. It does create a gap in ordering against other nodes. If the clock later returns to normal, later IDs from that node will have lower timestamps than the ones made during the jump. Those jump IDs look like outliers in sort order, but they stay unique. NTP normally smooths adjustments, so this is unlikely. In extreme cases, an operator can configure NTP to step slowly, or restart the service after the correction.

Concurrency and throughput on a node. The algorithm on one node is small. Read the clock in milliseconds. If it equals the last time, add one to the sequence. If it is a new time, reset the sequence to 0. Then pack the bits into the ID. That is a few CPU instructions. On a multi-threaded server we make it safe for calls that arrive at the same time:

• Guard the timestamp and sequence with a lock, or with an atomic compare-and-swap. The overhead is tiny. Some implementations instead use one thread that generates IDs in order and feeds a queue. Either way, a locked section with two comparisons and an increment handles millions of operations per second on a modern CPU. Our target of about 100k per second per node is only 100k lock operations per second, which is trivial.
• If one node must go faster, we could split the sequence range between threads. Thread 1 uses 0 to 2047 and thread 2 uses 2048 to 4095 within the same millisecond. That adds complexity we do not need. With many nodes available, we scale out instead of tuning one node to its limit.
• The node runs as a stateless service, likely an HTTP or RPC server. Each request runs the generation routine, which takes microseconds. Most of the request latency is therefore network time, not generation time. One thread can serve many requests per second. The service could batch internally, but one ID per request is fine at this throughput.

Integration with the API. The node formats the 64-bit ID into the response. Many systems return Snowflake IDs as decimal strings. Twitter exposes tweet IDs that way. We can do the same, or return a JSON number. Clients in languages with 64-bit integers can treat it as an integer, and databases can store it as a BIGINT. JavaScript is the exception. It stores numbers as floats and loses precision above 53 bits. An ID ending in 608 can silently come back ending in 600. Nothing raises an error, which is what makes that dangerous. So JavaScript clients must receive the ID as a string. It is an API detail, but it matters in implementation.

6.3 Opaque ID (UUID) Generation Design

The opaque ID design is simpler, because there is nothing to coordinate.

We use 128-bit UUID version 4 generation. That means 16 random bytes from a CSPRNG, a cryptographically secure pseudo-random number generator. We set the version and variant bits that UUID v4 requires, which mark the value as random. The result looks like f47ac10b-58cc-4372-a567-0e02b2c3d479, the canonical 8-4-4-4-12 hex format with hyphens. We could also return 32 hex characters without hyphens. The format does not change uniqueness.

Two random 128-bit values almost never collide. We treat it as impossible in practice. One cited estimate: generating 1 billion random UUIDs per second for 100 years gives about a 50% chance of a single collision. Our system makes maybe 10^10 per day, nowhere near that. So we do no coordination and no duplicate check. The size of the space is the guarantee. What is left to get right is the randomness source. Most languages provide a secure RNG, or a library call that returns a UUID directly.

Making a random 128-bit number is very fast. Formatting it as a string with hyphens costs more, and that is still trivial at our scale. Modern CPUs make millions of random numbers per second. Even a lock around one RNG handles 100k per second. If needed, thread-local RNG instances remove the contention. A secure RNG is a little slower than a plain one, but still microseconds per ID.

Each call is independent. Nothing is remembered between calls, so any node can answer an opaque-ID request at any time. This mode does not need the coordinator at all. There is no sequence and no time to manage. So none of the clock and machine ID failures from 6.2 can reach this path.

The security property is why we offer this format at all. The ID means nothing to an outsider. It reveals neither the time nor the origin. That is what we want when IDs appear in URLs or API responses. Users must not learn how many items exist or when one was created. If user IDs were sequential, an attacker could step from one valid ID to the next and scrape records. Random IDs make that search hopeless. The trade is that you cannot sort by creation time without a separate timestamp field.

The service returns the opaque ID as a string in UUID format, for example {"id": "de305d54-75b4-431b-adb2-eb6b9e546014"}. Clients treat it as an opaque token. If they need creation time, they store it separately, because the ID does not carry it. We could use UUIDv7 or ULID for a little ordering, but both leak time and would no longer be opaque. So the opaque variant stays purely random. Our advice to clients: use time-sortable IDs when you need order, and opaque IDs when you need unguessable values.

6.4 Data Storage and State Management

The design keeps persistent storage to a minimum. One decision explains the rest: uniqueness here is computed, never looked up.

So we do not store issued IDs in any database or log, beyond short-lived debug logs. Storage does not grow with the number of IDs. There is no distributed database or cache to run. Uniqueness comes from the structure of the ID, so there is nothing to check against. That matters for scale. Inserting 100k keys per second into a store would be the largest write load in the system, for no gain. Uniqueness is designed into the format instead, by time plus machine plus sequence, or by the size of the random space.

The only real state lives in the coordinator, ZooKeeper or etcd. It holds one small znode per active worker, a few bytes each, with perhaps the worker's address or ID. That is at most about a thousand entries, which is tiny. ZooKeeper keeps this in memory plus a small transaction log on disk.

This state must survive, so a full restart never assigns one machine ID twice. Since it is a few entries, backup and reload are easy. If the coordinator data were lost and every node restarted, we could briefly risk duplicate assignments. To prevent that, we would either configure IDs by hand in that scenario, or require coordinator recovery first. So we run the coordinator with disk persistence, and we may keep a mapping record alongside the ephemeral nodes.

We log operations, and we may keep a short in-memory audit window of recent IDs to catch anomalies like a duplicate. Logging every ID to disk is not practical. Instead we log counts per second and notable events, like a sequence rollover or a clock going backward. These logs help debugging. They are not part of the data path.

The service could also offer a method to parse or validate an ID: confirm the format, and perhaps decode the timestamp. That needs no stored data. It is pure arithmetic on the bits. For a Snowflake ID, shift right by 22 bits and add the epoch to recover the time. This would be a small utility API, not a major part.

6.5 Failure Recovery Details

Generator node failure. If a generator instance crashes or is removed, the IDs it already issued stay valid. They are just numbers, already in use by clients. Nothing has to be recovered, because the node was not holding work for anyone. The coordinator notices the lost session, since the ephemeral znode is gone, and frees that machine ID. An orchestrator like Kubernetes or an auto-scaling group starts a replacement. The new instance registers and may receive the same machine ID, if it is the next free one in that region.

If it does, we rely on the clock handling from 6.2. We assume the new clock is current. If the old instance's clock ran slightly ahead, the new one may produce IDs a little lower than the old node's last ones. Those values were never generated before, and the old node is offline, so there is still no duplicate. To be extra safe, a restarting node could take a different machine ID from the one that just failed. That uses up ID space unless managed, and with synchronized clocks it is not a major concern.

Datacenter outage. If a whole region goes down, its nodes stop generating. Clients fail over. For example, the load balancer routes to a secondary region. Region is encoded in every ID, so IDs from another region are still unique. Regions do not depend on each other, so the rest continue normally.

When the region returns, its nodes restart with the current time. Their new IDs are above anything they made before, because the timestamp is later. A long outage just means that region produced no IDs for a while. That is fine. IDs do not need to be contiguous, so there is no "hole" problem. Uniqueness is enough.

ZooKeeper failure. If the coordinator cluster fails completely, no new node can join. Existing nodes keep generating with the machine IDs they hold. One caution: a node that loses its session during a long outage might stop, if it was written to require a live ZooKeeper session. So we can design the generator to keep using its last known ID while ZooKeeper is unreachable, as long as it detects no conflict. It reconnects and reconciles when ZooKeeper returns.

Because ZooKeeper manages node IDs and not requests, even a slow ZooKeeper does not touch generation throughput. At runtime the system is almost fully decoupled from it, especially once every node has its ID. This is an engineering detail, but it keeps availability high.

Duplicate ID safeguards. The logic guarantees uniqueness in theory. In debug mode we can add runtime checks. A node might keep a sliding window of recent IDs, that is, the last N it produced, or just the last one. It then asserts that each new time-sortable ID is larger, or that each new random ID differs from the last. This is only to catch bugs. In production, storing a million recent IDs per node is too much, but storing the last one or the last timestamp is fine. For the rest we rely on the math.

Scaling beyond 1024 nodes. If we ever needed more than 1024 generator nodes at once, or more than 32 regions, we have options:

• Give more bits to the machine ID. Taking them from the timestamp shortens the time range. Taking them from the sequence lowers the per-node rate. For example, 12 machine bits and 10 sequence bits allow 4096 nodes, but only 1024 IDs per millisecond per node. With that many nodes, per-node throughput is not the limit, so the trade works.
• Deploy a second independent Snowflake service with a different epoch or a different ID namespace, like a prefix. That pushes work onto clients, which must know which service to call.
• Each node can make millions of IDs per second, so more than 1024 active nodes is unlikely. It would only happen if nodes were limited by something else, like network or CPU. 1024 nodes making millions each is far above our 100k per second target.

So the detailed design runs two algorithms in one service. Snowflake gives the time-sortable, high-throughput IDs, and a UUID-style random ID gives the opaque ones. Together they cover both functional requirements. What makes them safe is care in three places: the bit layout, the machine ID assignment, and the clock behavior. Snowflake and its derivatives are proven in production at Twitter and elsewhere, and UUIDs give the opaque path a well-understood standard.

Next: Step 7, which scales the chosen approach.