How do you design a unique ID generator in a distributed system?

Start with the requirements: unique forever, roughly sorted by time, 64 bits, high rate, no single point of failure. Then compare the options: a database counter, stepped ticket servers, UUIDv4, UUIDv7, Snowflake and segment allocation. For 64-bit IDs, pick a Snowflake-style layout: 41 bits of milliseconds since a custom epoch, a 10-bit machine ID leased from etcd or ZooKeeper, and a 12-bit sequence. Then explain the clock-goes-back and sequence-overflow cases.

How does Twitter Snowflake generate unique IDs?

Each Snowflake ID is a 64-bit number made of 41 bits of milliseconds since Twitter's custom epoch (4 November 2010), 10 bits of machine ID (5 for the datacenter and 5 for the worker in Twitter's code) and a 12-bit sequence. A machine makes up to 4,096 IDs per millisecond without asking anyone. Worker numbers were chosen through ZooKeeper at startup. If the clock moves backwards, the generator refuses to make IDs until time passes the last one used.

Should I use UUIDv4, UUIDv7 or Snowflake IDs as a primary key?

Avoid UUIDv4 for primary keys on large tables: RFC 9562 says non-time-ordered UUIDs have poor database-index locality, because random values land all over the B-tree. UUIDv7 starts with a 48-bit millisecond timestamp, so new keys go to the end of the index, and it needs no machine IDs, but it is 128 bits. A Snowflake ID is time-ordered and fits a 64-bit BIGINT, but needs machine IDs and clock care.

How many IDs per second can a Snowflake generator make?

The 12-bit sequence allows 4,096 IDs in each millisecond on one machine, which is 4,096 x 1,000 = 4,096,000 IDs a second. With 10 machine bits there can be 1,024 machines. If one machine uses all 4,096 numbers in a millisecond, it waits for the next millisecond instead of wrapping the counter, so it never repeats an ID.

What happens when the clock goes backwards in a Snowflake ID generator?

If the clock moves back, the generator could reuse a millisecond and make a duplicate ID. So it compares the current time with the last time it used. Twitter's code refuses to make IDs until the clock catches up. Meituan's Leaf waits for gaps of 5 ms or less and returns an error for bigger ones. To prevent it, run NTP so it slews the clock rather than stepping it back.

How did Instagram generate IDs across PostgreSQL shards?

Instagram put the Snowflake idea inside PostgreSQL. Each logical shard has a PL/pgSQL function that builds a 64-bit ID from 41 bits of milliseconds since a custom epoch, 13 bits of logical shard ID and 10 bits from a PostgreSQL sequence taken modulo 1,024. That allows 1,024 IDs per shard per millisecond. The ID is the column default, so no separate ID service is needed.

What is a UUID generator in system design?

A UUID generator makes 128-bit identifiers that any machine can create without asking any other. UUIDv4 fills 122 bits with random data. UUIDv7, defined in RFC 9562, starts with a 48-bit millisecond timestamp and fills most of the rest with random bits, so new IDs sort by time and insert at the end of a database index. PostgreSQL 18 has a built-in uuidv7() function.

What is the difference between a Snowflake ID and a UUID?

A Snowflake ID is 64 bits and fits a BIGINT column, but each generator needs its own machine ID and a clock that does not go backwards. A UUID is 128 bits and needs no coordination at all, because it relies on random bits. UUIDv7 is time-ordered like Snowflake; UUIDv4 is fully random. At 365 billion records a year, the key column alone is about 2.9 TB as Snowflake and 5.8 TB as UUID.

How do Flickr ticket servers work?

Flickr runs two MySQL servers that each hold a one-row table. REPLACE INTO bumps an auto-increment counter and SELECT LAST_INSERT_ID() reads the new number. One server is set to auto-increment-increment 2 and offset 1, giving odd numbers, and the other to offset 2, giving even numbers, so either can fail without stopping new IDs. Every ID costs a database round trip, and IDs from the two servers are not in time order.

System design interview guide

Design a Unique ID Generator in Distributed Systems: Snowflake, UUIDv7, Ticket Servers and Segments

Short answer

A unique ID generator gives every new record a number that is never used twice, across many servers, without a central bottleneck. The usual answer is a Snowflake-style 64-bit ID, made inside each app server with no network call. It has 41 bits of milliseconds since a chosen start date (the epoch), a 10-bit machine ID and a 12-bit sequence counter. That is 4,096 IDs per millisecond per machine, up to 1,024 machines, for about 69.7 years. Because time comes first, IDs sort roughly by creation time and new rows go to the end of a database index. Each machine leases its machine ID from etcd or ZooKeeper at startup. If the clock goes backwards, the generator waits or refuses, because reusing a millisecond could make a duplicate. If 128 bits are fine, a UUIDv7 needs no machine IDs and is also time-ordered; a random UUIDv4 scatters inserts across the index.

in this guide

Design a unique ID generator, part by part

8 parts open to everyone · 3 with a free account · 3 with the course

Requirementsopen
Scale estimatesopen

Why this question is asked

The question is small enough to finish in one interview, but it touches four hard things. Coordination: how do 500 servers avoid picking the same number without talking to each other on every request? Time: clocks on different machines disagree, and a clock can even jump backwards. Storage: the ID becomes the primary key, the main index of every table, so its size and its order affect every insert. And trade-offs, where you gain one thing by giving up another: there is no single best answer, only the right one for a set of requirements. A weak answer says 'use a UUID' and stops. A strong answer first asks what the ID must do: fit in 64 bits, sort by time, be hard to guess. Then it compares four or five schemes with numbers. It explains each part of the Snowflake layout with arithmetic. And it says exactly what the generator does when the clock goes back or the counter runs out inside one millisecond.

This page is the free part.

The course goes deeper on the unique ID generator design

₹499 in India$49 everywhere elseonce, for the whole course

The System Design course covers the unique ID generator design across a run of lessons, not one page. These 4 alone are about 152 minutes of step-by-step reading, 1 of them with code you run in the browser, all with a quiz.

Live from the course bench

Before you design Unique ID Generator in Distributed Systems, try the questions it rests on.

Real interview questions, live diagrams and measured lab results, pulled at random from the lessons. A new set every time you come back.

Two engineers sketching a system design on a whiteboard

where the work happens

Stuck on a card?

Ask the course tutor. It answers with a real diagram, drawn for your question.

Ask the tutor

Laying out the cards…

Requirements

Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.

Functional requirements

Return a new ID on every call, and never return the same ID twice, across every server and every restart
IDs sort roughly by creation time: an ID made a second later is bigger
IDs are numbers that fit in 64 bits, so they fit a BIGINT column

Go deeper

This guide is built on these 6 lessons. Each one teaches one piece of the unique ID generator design above, step by step.

Practice with 770 system design lessons

Lifetime access for ₹499 in India or $49 elsewhere. Interactive diagrams, quizzes, and 20 capstone projects to practise on.

Get lifetime access See all interview problems

Two courses by the author of this page:

System Design

770 lessons · 18 free to read

₹499 in India · $49 elsewhere, once

Get System Design

You own this course

AI Engineering

210 lessons · 10 free to read

₹999 in India · $49 elsewhere, once

Get AI Engineering

You own this course

Every lesson in both courses has an AI tutor beside it. It reads the same lesson you are reading and answers your questions from it. Try the tutor

Save your progress and get the interview checklist PDF

System Design Interview Cheat Sheet: the 7 interview stages, the 10 points a scorecard grades, 12 classic systems. 18 pages. Free with an account.

Every new row needs a name that no other row will ever have. A row is one record in a database table, such as one tweet. A tweet, a photo, an order, a chat message. On one database this is easy: the database counts 1, 2, 3. Now spread the data over 50 databases and 500 app servers. Each of them makes new rows at the same moment, and none of them wants to stop and ask the others. Two servers must never pick the same number, not even once in ten years. The numbers should also sort roughly by time, so asking the database for 'newest first' (a query) is fast and cheap. And they should fit in 64 bits (a bit is one binary digit, 0 or 1), because every index stores them. An index is a sorted list the database uses to find rows fast. Twitter's Snowflake packs all of this into one number: 41 bits of milliseconds, 10 bits of machine number, 12 bits of counter. That is 4,096 IDs per millisecond on each machine, with no network call.

A unique ID generator gives every new record a number that is never used twice, across many servers, with no central bottleneck. First, some terms. A bit is one binary digit, 0 or 1; 64 bits hold any whole number up to about 9.2 billion billion. A BIGINT is the database column type that holds a 64-bit whole number. An epoch is the fixed starting moment that a time count is measured from. The main options are these. A database counter (auto-increment: the database adds 1 for each new row) is simple. But it runs on one machine, so if that machine fails, nobody gets a new ID. Several databases can share the work by stepping: one gives odd numbers, one gives even numbers, which is how Flickr's ticket servers work. A UUID is a 128-bit ID. Version 4 is random, so any machine can make one without asking other machines, but is twice the size of a BIGINT and scatters new rows all over an index. Version 7, defined in RFC 9562 (an official internet standard), puts a 48-bit millisecond timestamp first, so new IDs land next to each other. Twitter's Snowflake builds a 64-bit number from three parts: 41 bits of milliseconds since a chosen epoch, a 10-bit machine ID, and a 12-bit sequence counter. That gives 4,096 IDs per millisecond per machine and about 69.7 years before the time bits run out. Instagram used the same idea inside PostgreSQL, with 13 bits for a shard number (a shard is one of the many databases that together hold the data) and 10 bits for the counter. Segment allocation hands each server a block of numbers from a database, such as 1,000 at a time, so the database is asked once per block, not once per ID. The hard parts are giving every machine a different machine ID, surviving a clock that jumps backwards, and handling more than 4,096 requests in one millisecond.

Roni Das

18 October 2026 · 41 min read

Where it shows up

This is a classic system design question. It is asked as 'design a unique ID generator', 'design a distributed sequence', 'how would you generate IDs across shards' or 'design Twitter Snowflake'. It is common at companies that shard their databases, such as social networks, chat apps, marketplaces and payment companies. It also appears inside bigger questions: the URL shortener, a chat system, a news feed and an order system all need IDs, and interviewers often stop to ask how you would make them.

Spec sheeta unique ID generator

01Peak ID rate: about 11,600 IDs a second on average, plan for 58,000 at peak
02What one Snowflake machine can make: 4,096,000 IDs a second
03How many machines can make IDs at once: 1,024
04How long the time bits last: about 69.7 years from the epoch

worked through below, with the maths

Data modelfree account

Deep dives (9)free account

The hard parts of this design are taught step by step in the System Design course: Design a URL Shortener, Database Indexing and B-Trees.

Design a URL Shortener
Design a URL shortening service like Bitly from scratch - hashing, storage, redirection, and analytics at scale.
65 min · diagrams · code you run · quiz
Database Indexing
The planner stopped using an index somewhere between 19.7 and 39.8 percent of the table. A query on the second column of a composite index took 37.269 ms against 0.054, and five indexes took the same inserts from 160 ms to 751.
26 min · diagrams · quiz
B-Trees
Ten million rows sat in three levels and a hundred rows in one. The same million keys took 21.4 MB inserted in order and 29.6 inserted at random, and after churn the index was 21.92 percent full.
26 min · diagrams · quiz
Database Sharding
Splitting a database across multiple servers, the nuclear option for scaling writes, and the architecture behind Instagram, Uber, and YouTube.
35 min · diagrams · quiz

all part of

System Design Masterclass

770 lessons · about 283 hours · 18 free to read

₹499in India, by UPI

$49everywhere else, by PayPal

Get the System Design course Read 18 lessons free first

You own this course

Continue with Design a URL Shortener

pay once,
yours for life

Support many ID streams if needed (one for users, one for orders), or one shared stream

Optionally: read the creation time back out of an ID

Non-functional requirements

High rate: tens of thousands of IDs a second in total, and much more at peak
Low latency (the wait for an answer): well under a millisecond when the generator runs inside the app server
No single point of failure (one part whose failure stops everything): one machine dying must not stop new IDs anywhere
No coordination on the hot path (the work done for every request): servers do not talk to each other for each ID
Long life: the scheme must not run out of numbers for decades
Safe under clock problems: a clock that jumps backwards must not create a duplicate

Back-of-envelope scale estimates

Show your math. Pulling numbers from thin air signals you have not thought about the load.

Peak ID rate

about 11,600 IDs a second on average, plan for 58,000 at peak

Interview assumption: 1 billion new records a day across all tables (posts, likes, messages, orders). 1,000,000,000 / 86,400 seconds = 11,574 a second on average. Assume the busiest hour runs 5 times the average: 11,574 x 5 = 57,870, so plan for about 58,000 IDs a second.

What one Snowflake machine can make

4,096,000 IDs a second

12 sequence bits give 2^12 = 4,096 IDs in each millisecond. 4,096 x 1,000 ms = 4,096,000 a second on one machine. So one machine could carry the whole 58,000 a second peak about 70 times. We still run the generator on many machines, but for availability and to avoid a network call, not for speed. Twitter's README promised at least 10,000 IDs a second per process, far below this ceiling.

How many machines can make IDs at once

1,024

10 machine bits give 2^10 = 1,024 different machine IDs. If every app server runs its own generator, the fleet can never go above 1,024 running generators at the same moment. With autoscaling (adding and removing servers automatically as traffic changes) and restarts, machine IDs must be returned and reused, which is why they are leased (see the deep dive on machine IDs).

How long the time bits last

about 69.7 years from the epoch

41 bits count up to 2^41 = 2,199,023,255,552 milliseconds. Divide by 1,000 (seconds), 86,400 (days) and 365.25 (years): about 69.7 years. Pick the epoch close to launch day, because every year between 1970 and the epoch is wasted. With an epoch of 1 January 2026 the bits run out in September 2095. Twitter's epoch is 4 November 2010, so its IDs run out in July 2080.

Key size: 64-bit Snowflake vs 128-bit UUID

about 2.9 TB vs 5.8 TB a year, for the key column alone

At 1 billion records a day, a year is 365 billion records. A 64-bit ID is 8 bytes: 365,000,000,000 x 8 = 2.92 TB. A 128-bit UUID is 16 bytes: 5.84 TB. That cost is paid again in every index and every other table that stores the ID, for example as a foreign key (a column that points at a row in another table).

Chance that two random UUIDv4s collide in a year

about 1 in 80 trillion

A UUIDv4 has 122 random bits (RFC 9562). With n random IDs, the chance that any two are equal is about n^2 / 2^123 (the birthday rule). For n = 365 billion: n^2 = 1.33 x 10^23, and 2^123 = 1.06 x 10^37, so the chance is about 1.25 x 10^-14, or 1 in 80 trillion. Random UUIDs are safe from collisions. Their problem is size and index order, not duplicates.

Segment size for a range allocator

about 35 million IDs per segment, one database write per 10 minutes

Meituan's Leaf article recommends a segment (a block of IDs handed out at once) of 600 times the peak IDs per second, which is 10 minutes of IDs. At 58,000 a second: 58,000 x 600 = 34,800,000 IDs per segment. At peak the database is asked for a new segment about once every 10 minutes, and less often per server when several servers share the traffic. Meituan says Leaf can keep issuing IDs for 10 to 20 minutes if the database goes down.

High-level architecture

The recommended design runs the generator as a small library inside every app server, not as a separate service. Draw four parts. First, the app servers, here Kubernetes pods. Kubernetes is a system that runs many copies of an app, and a pod is one running copy. Each holds a generator object with three numbers in memory: its machine ID, the last millisecond it used, and a sequence counter. When code needs an ID, it calls the generator. The generator reads the local clock and builds the ID from the time, the machine ID and the counter. There is no network call, so an ID takes microseconds. Second, a coordination service, such as etcd or ZooKeeper. A coordination service is a small, very reliable database that a cluster uses to agree on shared facts. Each server talks to it once at startup to lease a machine ID that no other running server holds. A lease is a claim that expires unless the holder keeps renewing it. Third, time. Every machine runs NTP, the Network Time Protocol, which keeps a machine's clock close to true time by asking time servers. The generator depends on the clock, so clock health is part of the design. Fourth, the databases, here PostgreSQL and MySQL shards (a shard is one of the databases that together hold the data). They store the ID in a BIGINT primary key column. Because new IDs are bigger than old ones, new rows go to the right-hand end of each index. An alternative design runs the generator as its own service with a few replicas behind a load balancer. That is useful when many languages need IDs, or when you want few machine IDs in use. It adds a network call to every ID (Twitter's README quoted a 2 ms response time plus network time), and the service must be as reliable as the databases.

In a real interview, sketch this on the whiteboard before diving into any single box.

One ID, from startup to the database

Follow pod ids-0 as it starts, then handles one 'create post' request. This is a good order to explain it in an interview.

1
Lease a machine ID
At startup the pod asks etcd to create the key /id-machines/0 with a lease of, say, 10 seconds, but only if the key does not exist yet. etcd does this in one step that cannot be split, called a compare-and-swap: it writes the key only if the key is still empty. If key 0 is taken, the pod tries the next number. The pod now owns machine ID 0 and renews the lease every few seconds.
2
Check the clock
Before it serves traffic, the pod checks that its clock is not behind the last time it, or any earlier holder of machine ID 0, used. If the clock is behind, it waits or refuses to start.
3
Request arrives
A user creates a post. The app code calls next_id() on the local generator object. No network call happens from here on.
4
Read the clock
The generator reads the current time in milliseconds, for example 1,000 ms after its last call.
5
Pick the sequence
The time is newer than the last one used, so the sequence resets to 0. If it were the same millisecond, the sequence would go up by 1. If that made it reach 4,096, the generator would wait for the next millisecond.
6
Build the number
id = (now - epoch) << 22 | machine_id << 12 | sequence. The << sign means shift left: move the bits that many places to make room. The | sign joins the three parts into one 64-bit number.
7
Insert the row
The app inserts the post with this ID as the primary key. The database does not have to make an ID, so the insert can go to any shard.
8
Send it to the client
The API sends the ID as a string, not a number. Discord's API docs always send IDs as strings 'to prevent integer overflows in some languages'. JavaScript is the common case: its largest exact whole number is 2^53 - 1, and a 64-bit ID can be bigger, so a browser would round it.

Core components

Walk through each service. The interviewer wants to hear what each one owns, not just the names.

ID generator library

A few dozen lines in each app server. It keeps the machine ID, the last millisecond used and the sequence. A lock makes sure two threads in one process never take the same sequence number. It reads the clock, handles the same-millisecond and clock-went-back cases, and returns a 64-bit number.

Machine ID registry (etcd or ZooKeeper)

Hands each running generator a machine ID that no other running generator holds. In etcd this is a key per machine ID, attached to a lease; etcd deletes every key attached to a lease when the lease expires. In ZooKeeper it is an ephemeral node, which ZooKeeper deletes when the session that created it ends. Twitter chose worker numbers through ZooKeeper at startup.

Clock and NTP

Each machine's clock, kept close to true time by NTP. The generator trusts the clock only to move forward. NTP should be set up to slew the clock (speed it up or slow it down a little) rather than step it (jump it to a new value), so it never jumps backwards in normal running.

Last-timestamp record

A small record, saved every few seconds per machine ID, of the latest millisecond used. A process that restarts reads it, so a restart after a clock change cannot reuse old milliseconds. Meituan's Leaf writes this time to ZooKeeper every 3 seconds and checks it at startup.

Database primary keys

A BIGINT column with no auto-increment. The app supplies the ID. Because the time comes first in the number, new rows go to the end of the index. Most databases store an index as a B-tree, a tree of pages kept in order, and its end is the cheapest place to insert.

Monitoring

Counts of clock-went-back events and their size, sequence overflows (calls that had to wait for the next millisecond), lease losses, and the gap between each machine's clock and NTP. Any one of these going up is an early warning of a duplicate.

the deep dive

Data model

machine ID lease (etcd key). Created with a compare-and-swap that only succeeds if the key does not exist. If the pod dies, the lease stops being renewed and the key is deleted when the TTL runs…

free with an account

Every table for a unique ID generator, its keys, and which store fits it and why.

One tap with Google. Free, no card.

the deep dive

Deep dives

The options side by side. There are six families of answer, and an interviewer expects you to know them all before picking one. One: a single database's auto-increment. The database keeps a…

free with an account

9 deep dives on the parts that break at scale, with 3 diagrams: The options side by side; The Snowflake bit layout and the arithmetic; Assigning machine IDs without duplicates.

One tap with Google. Free, no card.

the deep dive

Trade-offs to discuss

Library inside each app server vs a separate ID service. A library has no network call and no extra service to run, but every app server needs a machine ID, which uses up the 1,024 slots fast with autoscaling. A separate…

free with an account

7 decisions an interviewer expects you to defend, each with the alternative and why it loses here.

One tap with Google. Free, no card.

for course owners

What the interviewer asks next

Two servers came up with the same machine ID after an autoscaling event. What breaks, and how do you stop it?

with the System Design course

5 follow-up questions with model answers, the interview scorecard for this question, and a mock interview on Design a unique ID generator with the AI tutor.

Unlock with the course · $49One payment, lifetime access to every lesson.

How a unique ID generator actually does it

Twitter announced Snowflake in June 2010 because its move to Cassandra and sharded MySQL left it with no way to make unique IDs; the code splits the 10 machine bits into 5 datacenter and 5 worker bits and refuses to make IDs when the clock moves back. Instagram built the same idea inside PostgreSQL with a PL/pgSQL function per logical shard: 41 bits of time, 13 bits of shard ID and 10 bits of sequence. Flickr's 2010 post describes two MySQL ticket servers, one odd and one even, in production since January 2006. Discord uses 42-bit timestamps from a 2015 epoch and sends IDs as strings. MongoDB's ObjectId puts 4 bytes of seconds first. Sony's Sonyflake uses 10 ms ticks to last 174 years. Meituan's Leaf offers both a segment mode and a Snowflake mode with ZooKeeper-assigned workers. RFC 9562 standardised UUIDv7 in 2024, and PostgreSQL 18 ships uuidv7().

Sources

the question most readers have next

The interviewer's next question: what breaks when the unique ID generator design runs at full scale?

A whiteboard answer gets you through the first round. The follow-ups are about the parts that fail under real load. The lessons below teach them one at a time, starting with "Design a URL Shortener".

Where this is used in industry

The real examples, each with its source, are on this page: How a unique ID generator actually does it.

The lessons that teach the next part

Design a URL shortening service like Bitly from scratch - hashing, storage, redirection, and analytics at scale.
Design a URL ShortenerSystem Design course65 min
The planner stopped using an index somewhere between 19.7 and 39.8 percent of the table. A query on the second column of a composite index took 37.269 ms against 0.054, and five indexes took the same inserts from 160 ms to 751.
Database IndexingSystem Design course26 min
Ten million rows sat in three levels and a hundred rows in one. The same million keys took 21.4 MB inserted in order and 29.6 inserted at random, and after churn the index was 21.92 percent full.
B-TreesSystem Design course26 min
Splitting a database across multiple servers, the nuclear option for scaling writes, and the architecture behind Instagram, Uber, and YouTube.
Database ShardingSystem Design course35 min

Stuck on a step? Every lesson has an AI tutor beside it. Ask it your question and it answers from the lesson you are reading. Try the tutor

Get the free System Design Interview cheat sheet (PDF)

Where this is taught

System Design Masterclass

770 lessons · about 283 hours · 18 free to read

₹499 in India by UPI$49 elsewhere by PayPal, once, for life

See the System Design course

You own this course

Frequently asked questions

India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.

Free PDF · 79 pages

25 real tech interview questions, answered in full

Five from each of our AI, GenAI, Inference, Maths for ML and Forward Deployed packs. Each with a diagram and a model answer. Free by email.

Also by the same author

210 lessons · about 219 hours · 10 free to read

₹999 in India by UPI$49 elsewhere by PayPal, once, for life

See the AI Engineering course

what a reader said

The concepts were explained in a clear and structured way, with practical examples that made even complex system design topics easier to understand. I especially liked the focus on real-world architecture, scalability, trade-offs. The content was well designed, engaging, and highly useful for anyone looking to strengthen their system design skills. Highly recommended for software engineers preparing for system design interviews or wanting to build a stronger foundation in designing scalable systems.

Verified reader · System Design Masterclass · read 69 lessons · all reviews

Design a Unique ID Generator in Distributed Systems: Snowflake, UUIDv7, Ticket Servers and Segments

Design a unique ID generator, part by part

Why this question is asked

The course goes deeper on the unique ID generator design

Before you design Unique ID Generator in Distributed Systems, try the questions it rests on.