Choosing the Right Primary Key Strategy: UUID, Snowflake, Redis, and More

Major relational databases provide auto‑increment primary key strategies (MySQL AUTO_INCREMENT, SQL Server IDENTITY, Oracle SEQUENCE). While simple and space‑efficient, auto‑increment keys can cause conflicts in integrated systems, become a bottleneck under high concurrency or distributed workloads, and expose business volume.

1. UUID mode

Universally Unique Identifier (UUID) is generated by standard algorithms without a central authority, offering near‑zero collision probability. Versions include time‑based, DCE‑secure, name‑based ( UUID(MD5), UUID.nameUUIDFromBytes()), random ( UUID.randomUUID().toString()), and SHA1‑based. Versions 1/2 suit distributed environments; versions 3/5 are deterministic; version 4 (random) is generally recommended despite a minuscule duplicate risk. Drawbacks: large storage, lack of order, poor sorting performance, and potential security concerns if MAC addresses are embedded.

2. Step mode

Also known as the Flickr sharding scheme, this approach uses multiple database servers with distinct start values and a consistent increment step, ensuring unique keys across shards.

While it mitigates some high‑concurrency issues, it introduces challenges such as difficult scaling, non‑strictly monotonic IDs, and the need for a database read/write on each ID request.

3. Segment mode

When an application requests IDs, it fetches the current maximum ID from the database and reserves a range of max+step. After consuming the range, it requests the next step ‑sized segment. This requires a dedicated table to store id, max_id, step, and optionally a version field for optimistic locking.

Segment mode reduces database round‑trips and allows the service to continue operating briefly if the DB becomes unavailable, though a service restart may lose unused IDs, causing gaps.

Production implementations include Meituan’s Leaf‑segment with double‑buffer caching and high‑availability optimizations, and Didi’s TinyId which extends Leaf with multi‑DB support and a dedicated client.

4. Snowflake mode (Twitter Snowflake)

Twitter’s distributed ID algorithm composes a 64‑bit number:

1 bit: sign (always 0 for positive IDs)

41 bits: timestamp in milliseconds (covers ~69 years)

10 bits: machine identifier (5 bits for data‑center, 5 bits for worker)

12 bits: sequence number within the same millisecond (up to 4096 IDs per ms)

Advantages:

IDs are time‑ordered on each node, enabling chronological sorting.

Generation does not depend on a database; it can be done in the application.

No duplicate IDs across a distributed cluster.

Bit allocation can be customized to fit business needs.

Disadvantages:

Time‑clock rollback can cause duplicate IDs.

Large clusters increase the cost of configuring worker IDs.

Meituan’s Leaf‑snowflake uses ZooKeeper to mitigate clock‑rollback issues, while Baidu’s UidGenerator allows custom timestamps, worker IDs, and sequence numbers.

5. Redis mode

Redis atomic commands INCR and INCRBY can generate sequential IDs. By deploying a Redis cluster, concurrency is greatly improved, similar to the step mode but with higher throughput.

Persistence is required because a Redis restart or failure would lose the current counter. Redis offers two persistence mechanisms: RDB: snapshotting; may lose recent writes and cause duplicate IDs after recovery. AOF: append‑only log; guarantees no duplicate IDs but can increase recovery time due to log replay.

In summary, the five primary key generation strategies—auto‑increment, UUID, step, segment, Snowflake, and Redis—provide different trade‑offs. Choose the one that aligns with your system’s concurrency, distribution, and durability requirements to optimize database performance and stability.