Designing a Distributed Global Unique ID Generation System: From UUID to Snowflake

Introduction

In large distributed systems a globally unique identifier is essential for data and message tracking; this article offers a comprehensive approach to designing such an ID generation scheme.

Problem & Requirements

Unique IDs are needed for services like finance, payments, orders, and coupons, especially after database sharding. The ID must be globally unique, trend‑increasing, monotonic, secure (hard to guess), and contain a timestamp.

Common Solutions

UUID

Generated locally via UUID.randomUUID(), UUIDs are 128‑bit strings (36 characters) but are unordered, causing poor index performance in MySQL B‑tree indexes and high storage overhead.

Database Auto‑Increment

Uses REPLACE INTO to obtain an auto‑incremented primary key. While it provides monotonicity, it does not scale well across many nodes and suffers from high latency and limited QPS.

Redis Atomic Counter

Redis’s single‑threaded INCR / INCRBY commands can generate sequential IDs. In a cluster, each node can be assigned a distinct start value and step (e.g., five nodes with steps of 5) to avoid collisions, though cluster maintenance is complex.

Snowflake Algorithm

Twitter’s Snowflake generates 64‑bit IDs composed of:

1 sign bit (always 0)

41 bits timestamp (millisecond precision, ~69 years range)

5 bits datacenter ID

5 bits worker ID

12 bits sequence number per millisecond

This structure ensures trend‑increasing IDs, high throughput, and no central coordination.

Java Implementation

/**
 * twitter's snowflake algorithm -- java implementation
 */
public class SnowFlake {
    private static final long START_STMP = 1480166465631L;
    private static final long SEQUENCE_BIT = 12;
    private static final long MACHINE_BIT = 5;
    private static final long DATACENTER_BIT = 5;
    private static final long MAX_DATACENTER_NUM = -1L ^ (-1L << DATACENTER_BIT);
    private static final long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);
    private static final long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);
    private static final long MACHINE_LEFT = SEQUENCE_BIT;
    private static final long DATACENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;
    private static final long TIMESTMP_LEFT = DATACENTER_LEFT + DATACENTER_BIT;
    private long datacenterId;
    private long machineId;
    private long sequence = 0L;
    private long lastStmp = -1L;
    public SnowFlake(long datacenterId, long machineId) { /* validation omitted */ }
    public synchronized long nextId() { /* core logic omitted */ }
    private long getNextMill() { /* omitted */ }
    private long getNewstmp() { return System.currentTimeMillis(); }
    public static void main(String[] args) { /* demo omitted */ }
}

SpringBoot Integration

Using Hutool’s IdUtil.createSnowflake(workerId, datacenterId):

<dependency>
    <groupId>cn.hutool</groupId>
    <artifactId>hutool-all</artifactId>
    <version>5.3.1</version>
</dependency>

public class SnowFlakeDemo {
    private long workerId = 0;
    private long datacenterId = 1;
    private Snowflake snowFlake = IdUtil.createSnowflake(workerId, datacenterId);
    @PostConstruct
    public void init() { /* convert IP to workerId */ }
    public synchronized long snowflakeId() { return snowFlake.nextId(); }
    public static void main(String[] args) { /* multi‑thread demo */ }
}

Advantages & Disadvantages

Pros

IDs are trend‑increasing due to timestamp in high bits.

No dependency on external databases; high performance and stability.

Bit allocation is flexible for different business needs.

Cons

Relies on accurate system clocks; clock rollback can cause duplicates.

Across nodes, strict global monotonicity is not guaranteed, only trend‑increasing.

Other Alternatives

Projects such as Baidu’s UidGenerator and Meituan’s Leaf provide alternative distributed ID generators.