DEV Community: Nasim Hossain Rabbi

How Twitter Solved Distributed ID Generation

Nasim Hossain Rabbi — Thu, 06 Aug 2026 17:02:40 +0000

"Generating an ID is easy."

Is it, though?

Every second, companies like Amazon, Stripe, Uber, Discord, and Netflix create millions of new records. Every order, payment, message, notification, and user account needs exactly one thing in common: a unique identifier.

It sounds almost trivial. Just keep an integer and increment it:

1, 2, 3, 4, 5...

Problem solved. Right?

Now imagine your application no longer runs on a single server. It looks more like this:

      Load Balancer
            │
┌───────────┴───────────┐
│                        │
Server A          Server B
│                        │
└───────────┬───────────┘
            │
    Millions of Requests

Server A and Server B both receive a request at the exact same moment. Both independently decide the next ID should be 10542.

Congratulations. Two customers now own Order #10542. Your database is confused, your monitoring is screaming, and somewhere a backend engineer just canceled dinner plans.

Distributed systems have a remarkable talent for turning simple problems into fascinating engineering challenges. Counting is one of them.

Why IDs Matter More Than You'd Think

Almost every backend system depends on unique IDs. Consider a typical e-commerce platform: when a customer places an order, several services spring into action at once — Order, Payment, Inventory, Shipping, Notifications — each storing data independently.

Every record they create needs an identifier that is:

Unique — no exceptions, ever
Fast to generate — without becoming a bottleneck
Scalable — able to grow with the system
Reliable — available even when parts of the system aren't

What Makes an ID Generator "Good"

Let's define what "good" actually means for a production system. A solid ID generator should satisfy most of the following:

1. Global uniqueness. No two IDs should ever collide.

2. High throughput. A payment gateway or messaging platform might need millions of IDs per second.

3. Low latency. An API shouldn't wait hundreds of milliseconds for an ID. Ideally, this takes microseconds.

4. High availability. If one server crashes, the platform shouldn't stop creating records.

5. Scalability. A startup running on two servers today might run on two thousand next year.

The Obvious Solutions (and Why They Fall Apart)

Before reaching for something sophisticated, it's worth understanding the intuitive approaches. Because most of them work fine, right up until they don't.

Database `AUTO_INCREMENT`

The simplest option by far:

CREATE TABLE users (
    id BIGINT AUTO_INCREMENT,
    name VARCHAR(255)
);

Simple, reliable, easy to reason about. So what's the catch?

Picture every application server sending inserts to the same database:

App Server A ───┐
                 │
App Server B ───┼──► Database
                 │
App Server C ───┘

The database becomes the sole authority for every ID in the system. A textbook single point of failure. If it slows down, everything slows down. If it goes offline, nothing can be created. And as you add more servers, scaling only gets harder, not easier.

Random Numbers

Just generate a random integer?

8349284
1293874
7239182

Fast, and requires no coordination between servers. The catch is that... the more IDs you generate, the higher the odds of a collision.

UUID v4

Most developers have run into a UUID at some point:

550e8400-e29b-41d4-a716-446655440000

UUID v4 draws from such a large space of random bits that the odds of a collision are effectively negligible. It needs no central coordinator, no assigned machine IDs, and works virtually anywhere.

So why doesn't everyone just use UUIDs?

The Hidden Cost of Randomness

Most databases store rows physically ordered by primary key. Sequential IDs append neatly to the end:

Databases love this — it's cheap and predictable. Now insert random UUIDs instead:

4fd2...
9ac1...
1ab7...
7de3...

Each insert can land anywhere inside the index. The database is constantly reshuffling its internal B-tree structure, which means more page splits, worse cache locality, and slower writes. On a laptop with a toy dataset, you'll never notice. At millions of inserts a day, it becomes a real, measurable cost.

Enter Twitter Snowflake

By 2010, Twitter was generating millions of tweets across hundreds of servers every day. Each tweet needed a unique ID, but relying on a central database to issue them had become a serious bottleneck.

So Twitter introduced Snowflake.

The idea was simple:

Let every machine generate its own IDs instead of asking a central service.

No database calls. No global locks. Minimal coordination.

Just a 64-bit number that each server can build on its own.

Snowflake encodes three things into every ID:

When it was created
Which machine created it
Which sequence number it was within that millisecond

With this, every server can independently generate unique, roughly time-ordered IDs at massive scale.

The Philosophy Behind Snowflake

Picture an e-commerce platform running hundreds of application servers. Every time an order comes in, a server needs a unique Order ID. One option is to ask a database for it hundreds of thousands of times per second.

Your database quickly becomes everyone's least favorite coworker: the one who gets interrupted every few seconds until they can't get anything else done.

Snowflake removes that dependency entirely. Every server generates IDs locally using only three pieces of information:

the current timestamp,
its own machine ID,
and a small counter for IDs created within the same millisecond.

No central coordinator. No lock contention. No network latency.

The Anatomy of a Snowflake ID

A Snowflake ID is a 64-bit signed integer. The highest bit is always 0, ensuring the value remains positive. The remaining 63 bits are divided into three fields:

┌──────┬──────────────┬───────────┬──────────┐
│ Sign │  Timestamp   │ Worker ID │ Sequence │
├──────┼──────────────┼───────────┼──────────┤
│ 1 bit│    41 bits   │  10 bits  │ 12 bits  │
└──────┴──────────────┴───────────┴──────────┘

Each field has a specific job.

Timestamp (41 bits)

The largest portion stores time, but not as a Unix timestamp. Instead, Snowflake records the number of milliseconds elapsed since a custom epoch chosen by your application.

current_time - custom_epoch

Using a custom epoch makes better use of the available bits. With 41 bits, you can represent roughly:

2^41 ≈ 2.2 trillion milliseconds ≈ 69 years

Starting from a recent date, such as 2025-01-01, gives your system decades of usable IDs without wasting range on years before your application even existed.

Worker ID (10 bits)

Each machine in the system is assigned a unique identifier.

Worker A → 1
Worker B → 2
Worker C → 3

With 10 bits, Snowflake supports up to 1,024 independent ID generators, allowing every server to produce IDs without coordinating with the others.

Sequence (12 bits)

Multiple IDs can be generated during the same millisecond by the same machine.

To keep them unique, Snowflake maintains a sequence counter:

0, 1, 2, 3 ... 4095

This allows a single worker to generate up to 4,096 IDs per millisecond, or roughly 4.1 million IDs per second.

Putting It All Together

Suppose a server generates an ID with:

timestamp = 100101...
worker    = 17
sequence  = 28

Each value is shifted into its assigned position and combined using bitwise OR:

id = (timestamp << 22) | (worker << 12) | sequence

The result is a single integer, something like:

739847238947239482

To your application, it's just another number.

Under the hood, it quietly encodes when it was created, which machine created it, and which request it was within that millisecond — all packed into 64 bits.

Why Databases Love Snowflake

Snowflake's biggest advantage isn't really uniqueness. It's ordering.

Random UUIDs insert like this:

A9F...
123...
FFE...
8C1...

...forcing the database to constantly rewrite parts of its index. Snowflake IDs, by contrast, arrive like this:

New rows land near the end of the index almost every time, which means:

fewer B-tree page splits
better cache locality
higher write throughput
less index fragmentation over time

Sometimes the choice of ID format is, quietly, a database performance decision.

Final Thoughts

So... generating an ID is easy.

Until it isn't.

Snowflake solves the obvious problem with an elegant design, but it also reveals a deeper truth: in distributed systems, the challenge is rarely the algorithm itself. It's building an environment where that algorithm can keep working correctly as machines, traffic, and infrastructure continue to evolve.

That's why Snowflake is still studied today. Not because packing bits into an integer is particularly difficult, but because it demonstrates a timeless engineering principle.

Sometimes the hardest part of a distributed system isn't processing billions of requests. It's simply agreeing on the next number.

A Disk Usage Alert Led Me Down the OpenStack Rabbit Hole

Nasim Hossain Rabbi — Mon, 27 Jul 2026 05:50:30 +0000

It Started With a Disk Usage Alert

While going through our monitoring dashboards, I noticed that one of our backup object storage servers had been experiencing high disk usage for quite some time. Since the issue had remained unresolved, I decided to take ownership of the investigation.

Our existing disaster recovery setup consisted of two independent single-node OpenStack Swift deployments. Instead of native replication, data was periodically copied from the primary server to the backup server using a custom synchronization process, where objects were downloaded, staged on the backup server, and then uploaded back into its own Swift instance.

After reviewing the existing architecture and previous discussions, I found that several approaches had already been proposed. These included using rsync or rclone for more efficient synchronization, inotifywait for near real-time replication, and even introducing a Virtual IP (VIP) with Keepalived to improve failover. Each proposal addressed a specific operational challenge and aimed to improve disaster recovery.

The more I read, however, the more I realized that we were continuously adding new components and operational logic around keeping two completely independent object storage systems in sync.

Rather than deciding which approach to implement, I stepped back and asked a simpler question:

There had to be a simpler way!

That question eventually led me to explore OpenStack Swift's native clustered architecture, where many of these challenges are already solved by design.

Discovering OpenStack Swift

While searching for a simpler approach, I discovered that the architecture already includes concepts like distributed storage, replication, fault tolerance, and self-healing clusters.

In other words, many of the problems we were trying to solve manually had already been solved years ago.

Instead of copying files between independent servers and building increasingly complex synchronization logic, Swift is designed to run as a cluster where data is automatically replicated across storage nodes.

The more I read, the more one question kept coming back:

Why weren't we using the architecture it was originally designed for?

I don't know the answer. Every organization has historical decisions, constraints, deadlines, and trade-offs.

But discovering the intended architecture was a genuine "wait... this already exists?" moment.

That Rabbit Hole Became OpenStack

Naturally, curiosity won.

What started as learning about OpenStack Swift quickly turned into learning about OpenStack itself.

That's when I realized Swift is just one service in a much larger ecosystem.

OpenStack isn't simply an object storage solution. It's an open-source cloud platform that provides the building blocks needed to build your own private or public cloud, much like the services offered by AWS or Azure.

Many of its core projects have direct counterparts in the public cloud world:

OpenStack	Purpose	AWS Equivalent	Azure Equivalent
Nova	Virtual machines	Amazon EC2	Azure Virtual Machines
Neutron	Networking	Amazon VPC	Azure Virtual Network
Swift	Object storage	Amazon S3	Azure Blob Storage
Cinder	Block storage	Amazon EBS	Azure Managed Disks
Keystone	Identity & access management	AWS IAM	Microsoft Entra ID (Azure AD)
Horizon	Web management dashboard	AWS Management Console	Azure Portal
Heat	Infrastructure as Code	AWS CloudFormation	Azure Resource Manager (ARM)

OpenStack vs Public Clouds

One realization that helped everything click was understanding that OpenStack isn't competing with AWS or Azure in the traditional sense.

AWS and Azure are cloud providers. You consume their services.

OpenStack is a cloud platform. You deploy and operate it yourself.

Think of it this way:

Public Cloud	OpenStack
Rent infrastructure from a provider	Build and operate your own cloud
Provider manages the platform	You manage the platform
Pay as you go	Run on your own hardware
Best for public cloud workloads	Best for private, hybrid, or sovereign clouds

Once I looked at it from that perspective, the similarities between the services made much more sense. Nova isn't trying to replace EC2 as a business. It's providing the compute building block that lets you build a cloud platform with capabilities similar to what EC2 offers.

A Surprisingly Interesting Origin Story

The story behind OpenStack is just as interesting as the technology itself.

OpenStack was launched in 2010 through a collaboration between NASA and Rackspace. Yes, that NASA.

At the time, cloud computing was taking off, with providers like AWS leading the market. Instead of building another proprietary cloud, NASA and Rackspace set out to create an open-source cloud platform that anyone could deploy, modify, and contribute to.

The project began by combining NASA's Nova compute project with Rackspace's object storage technology. Over the years, it grew into one of the world's largest open-source infrastructure projects, supported by thousands of contributors and hundreds of organizations.

Today, OpenStack powers private and public clouds worldwide and is governed by the OpenInfra Foundation, now part of the Linux Foundation, continuing its mission of making cloud infrastructure open and accessible.

The Best Part

This whole journey started because of a disk usage alert.

I wasn't trying to learn about cloud architecture.

I wasn't researching OpenStack.

I certainly wasn't planning to spend hours reading about distributed object storage.

I was simply following a problem.

Sometimes that's how the best learning happens.

You pull on one thread, and suddenly you're exploring an entire ecosystem that has been quietly solving problems for more than a decade.

What's Next?

I'm planning to explore more of OpenStack over the coming weeks, especially how its different services work together to build a complete cloud platform.

If you've never looked into it before, I'd highly recommend spending some time exploring its projects and architecture.

Who knows?

You might start by investigating a simple monitoring alert and end up learning how an entire cloud platform is built.

Just be warned: building your own cloud sounds surprisingly achievable right up until you realize you're about to recreate a small part of AWS in your spare time. That's usually when you gain a whole new level of respect for the engineers who build and operate these systems every day.

Sometimes the best learning doesn't start with a tutorial. It starts with a production issue and a bit of curiosity. Happy exploring!