In a single-database system, you get unique IDs for free. Set a column to AUTO_INCREMENT, and the database hands out 1, 2, 3, ... forever. Simple, sequential, and guaranteed unique. But the moment you split into multiple databases, microservices, or sharded storage, that trick falls apart. There is no single authority to hand out sequential numbers anymore. Two services inserting at the same millisecond could both try to claim ID 42. You need a strategy that produces globally unique identifiers without a central coordinator — or at least without one that becomes a bottleneck. This matters more than you might think. IDs show up everywhere in a distributed system: every message in [Slack](/learn/system-design/questions/slack), every ride in [Uber](/learn/system-design/questions/uber), every payment in a [Payment](/learn/system-design/questions/payment) system, every event in [Google Calendar](/learn/system-design/questions/google-calendar). Getting ID generation wrong means data corruption, duplicate records, or a throughput ceiling that chokes your entire platform. ## The Auto-Increment Problem Let us start with why the obvious solution breaks down. If every service calls a single database to get the next ID, that database becomes a funnel everything must pass through. Every service must acquire a lock, increment the counter, and release the lock. At 10K IDs per second, you hit a wall — and adding more application servers only makes the contention worse, not better. This is the same fundamental problem discussed in [Dealing with Contention](/learn/system-design/design-patterns/dealing-with-contention): a shared mutable resource becoming a serialization point. You have two paths forward: eliminate the central coordinator entirely (UUID, Snowflake, ULID) or reduce how often you need to talk to it (batch allocation). ## UUID v4 — The Zero-Coordination Approach The simplest distributed ID strategy is to generate random numbers that are so large, collisions are practically impossible. That is UUID v4 in a nutshell: 122 random bits, producing something like a3f2b1c4-9d8e-4f7a-b6c5-1a2b3c4d5e6f. Any node can generate one independently, with no network calls and no coordination. The probability of a collision is about 1 in 2^122 — you would need to generate 2.7 quintillion UUIDs before having a 50% chance of a single duplicate. So why doesn't everyone just use UUIDs? Two problems. First, **randomness kills database performance.** B-tree indexes work best when new keys are appended to the end, which keeps pages sequential on disk. Random UUIDs scatter inserts across the entire index, causing page splits, fragmentation, and more disk I/O. For write-heavy tables, this can reduce insert throughput by 2-5x compared to sequential IDs. This connects directly to the storage engine trade-offs discussed in [Scaling Writes](/learn/system-design/design-patterns/scaling-writes) — random writes are the enemy of B-trees. Second, **UUIDs are not time-ordered.** If you want to query "show me the 50 most recent orders," a UUID-based primary key gives you no help. You need a separate indexed timestamp column, which means maintaining two indexes instead of one. **See it in practice:** In [File System](/learn/system-design/questions/file-system), UUIDs work well for file and chunk identifiers because files are accessed by path, not scanned in insertion order. In [Remote DevBox](/learn/system-design/questions/remote-devbox), session IDs are naturally random-access — nobody queries "give me the 100 most recent sessions in order." ## Snowflake IDs — The Best of Both Worlds Twitter faced the UUID trade-off head-on: they needed IDs that were unique without coordination but also roughly time-ordered for efficient timeline queries. Their solution, Snowflake, has become the gold standard. A Snowflake ID packs four pieces of information into a single 64-bit integer: The beauty of this design is that **the timestamp occupies the most significant bits.** This means Snowflake IDs are naturally sorted by time — newer IDs are always numerically larger than older ones. Your database index stays sequential, just like auto-increment, but without any central coordinator. Each machine knows its own datacenter ID and machine ID (assigned at deployment time). Within a millisecond, the sequence counter handles bursts of up to 4,096 IDs. If you exhaust the sequence within a single millisecond, the generator simply waits until the next millisecond — a rare event in practice. ### The Dedicated ID Service Pattern In large-scale systems, the Snowflake algorithm typically runs as a dedicated service rather than being embedded in every application. Twitter, Discord, and Instagram all run variations of this pattern. The ID service itself is stateless (it only needs to know the current time and its machine ID), which makes it easy to scale horizontally and replicate across datacenters. **See it in practice:** In [Distributed Counters](/learn/system-design/questions/distributed-counters), Snowflake-style IDs are used to generate unique event identifiers across distributed counter nodes. In [Ads Click Aggregator](/learn/system-design/questions/adds-click-aggregator), time-ordered IDs let you efficiently aggregate clicks within time windows. In [Leaderboard](/learn/system-design/questions/leaderboard), sortable IDs enable tie-breaking by insertion time. ### Clock Skew: The One Gotcha Snowflake depends on system clocks being reasonably synchronized. If a machine's clock jumps backward (after an NTP correction, for example), the generator could produce IDs with timestamps in the past — breaking the monotonic ordering guarantee and potentially creating duplicates. The standard defense is simple: if the generator detects the clock has moved backward, it refuses to generate IDs until the clock catches up. Twitter's original implementation would throw an error and let the caller retry. In practice, NTP keeps clocks within a few milliseconds, so this happens rarely — but your system must handle it gracefully rather than silently producing bad IDs. ## ULID — UUID-Sized, Time-Sorted ULID (Universally Unique Lexicographically Sortable Identifier) is a newer approach that combines the universality of UUIDs with the time-ordering of Snowflake. A ULID is 128 bits: 48 bits of millisecond timestamp followed by 80 bits of randomness, encoded as a 26-character Crockford Base32 string like 01ARZ3NDEKTSV4RRFFQ69G5FAV. ULIDs are time-sorted (the timestamp prefix ensures lexicographic ordering matches chronological ordering), need no coordination, and are more compact than UUID strings (26 chars vs 36). The trade-off compared to Snowflake: they are twice the size (128 bits vs 64 bits), which matters for storage and index efficiency at very high scale. ## Batch Counter Allocation Sometimes you genuinely need sequential, gap-free (or near gap-free) IDs — for example, invoice numbers or ticket numbers that humans read and compare. In that case, you cannot avoid a central counter entirely, but you can drastically reduce how often you talk to it. The idea: a coordination service assigns each application server a range of IDs. Server A gets 1-10,000, server B gets 10,001-20,000, and so on. Each server hands out IDs from its range locally with zero network calls. When a range runs out, the server requests a new batch. This gives you sequential-ish IDs (monotonic within each server, roughly ordered globally) with minimal coordination overhead. The trade-off: gaps appear when a server crashes with unused IDs in its batch, and IDs are not strictly monotonic across servers. For the [CI/CD](/learn/system-design/questions/cicd) question, where build numbers need to be human-readable and roughly sequential, batch allocation hits the sweet spot. ## Hash-Based IDs For content-addressable systems, hashing the content itself produces the ID. Hash a URL with SHA-256 and you get a deterministic, reproducible identifier. Two nodes hashing the same URL independently will always get the same ID — which is either a feature (deduplication) or a bug (collisions with truncation), depending on your use case. In [Bookstore](/learn/system-design/questions/bookstore), hashing the ISBN produces a natural content-based key. In a [Cache](/learn/system-design/questions/cache), hashing the cache key determines which shard stores the value — the same technique behind [Distributed Caching](/learn/system-design/design-patterns/distributed-caching) and consistent hashing. The main risk is **collision handling with truncation.** A full SHA-256 hash (256 bits) has negligible collision probability, but if you truncate to, say, 7 characters of Base62 for a URL shortener, collisions become likely as the keyspace fills up. Always enforce a unique constraint at the storage layer and retry with a different salt on collision. ## Choosing the Right Strategy Here is the decision framework in practice: - **Need time-ordered IDs at massive scale?** Snowflake. This covers most system design questions: [Slack](/learn/system-design/questions/slack) messages, [ChatGPT](/learn/system-design/questions/chatgpt) conversation events, [Online Chess](/learn/system-design/questions/online-chess) move records, [Facebook Post Privacy](/learn/system-design/questions/facebook-post-privacy) post IDs. - **Need IDs that work everywhere with no setup?** UUID v4. Great for [Webhook](/learn/system-design/questions/webhook) delivery IDs, [Job Scheduler](/learn/system-design/questions/job-scheduler) task IDs, and idempotency keys (see [Idempotency and Exactly-Once](/learn/system-design/design-patterns/idempotency-exactly-once)). - **Need deduplication built in?** Hash-based. Used in [Web Crawling and Data Pipelines](/learn/system-design/design-patterns/web-crawling-data-pipelines) to avoid recrawling the same URL and in [Crossword Puzzle](/learn/system-design/questions/crossword-puzzle) to deduplicate puzzle states. - **Need human-readable sequential numbers?** Batch counter. Think invoice IDs, build numbers, or ticket numbers. ## Collision Handling Regardless of strategy, always defend against collisions at the storage layer: 1. **Database unique constraint:** The INSERT fails if a duplicate ID exists — this is your safety net and should always be present. 2. **Retry with different input:** On failure, append a counter or random suffix to the input and regenerate. For hash-based IDs, this means re-hashing with a salt. 3. **Monitor collision rates:** For truncated hashes, collision frequency grows as the keyspace fills. Track collision rates and increase ID length before the rate becomes problematic. The check-then-insert pattern (query for existence, then insert) is unreliable under concurrency because two threads can both check, both find no conflict, and both insert. Always prefer the unique constraint approach — let the database be the arbiter. **Cross-cutting patterns:** Unique ID generation intersects with several other patterns. [Idempotency and Exactly-Once](/learn/system-design/design-patterns/idempotency-exactly-once) relies on unique request IDs to detect duplicates. [Event Sourcing and CQRS](/learn/system-design/design-patterns/event-sourcing-cqrs) needs ordered event IDs for correct replay. [Stream Processing and Real-Time Aggregation](/learn/system-design/design-patterns/stream-processing-realtime-aggregation) uses time-embedded IDs for windowed aggregation. [Pub/Sub Messaging](/learn/system-design/design-patterns/pub-sub-messaging) needs unique message IDs for deduplication and ordering. The [Top-K](/learn/system-design/questions/topk) and [LeetCode](/learn/system-design/questions/leetcode) questions both benefit from sortable IDs when ranking results by recency.