Use Cases for Distributed IDs

In the monolithic era, traditional database auto-incrementing primary keys easily fulfilled most business requirements. However, as modern architectures transition toward microservices and database sharding, auto-increment sequences maintained independently by different database instances inevitably collide. Consequently, globally unique identifiers have become an indispensable component of foundational infrastructure. This article explores the typical use cases and architectural selection strategies for distributed IDs in real-world business scenarios.

Before designing or adopting a distributed ID solution, several core metrics must be defined:

• Global Uniqueness: Identifiers must not collide across the entire cluster and cross-datacenter environments.
• Monotonically Increasing Trends: This property optimizes storage engines like InnoDB in maintaining balanced indices, preventing frequent page splits.
• High Performance and High Availability: ID generation usually sits on the critical request path, requiring latencies well within the millisecond range.
• Information Security (Optional): Publicly exposed IDs should avoid leaking business scale data; for instance, sequential order IDs inadvertently expose transaction volumes.
  This represents the most classic use case for distributed IDs. Taking an e-commerce order system as an example, once the order table is sharded via user_id hashing into 16 databases and 256 tables, the locally maintained auto-increment keys will certainly conflict. To resolve this, systems commonly adopt the Snowflake algorithm to generate 64-bit IDs:

0 | 41-bit Timestamp | 10-bit Machine ID | 12-bit Sequence

These IDs are globally unique and monotonically increasing, making them ideal as physical primary keys post-sharding. Meanwhile, this approach prevents data skew issues that often arise when using business fields like phone numbers as sharding keys.

Scenario 2: Business Document Numbers (Orders, Payments)

Document numbers exposed externally are usually decoupled from database primary keys and typically demand:

• Uniqueness combined with a degree of readability to assist customer support and operations teams in troubleshooting.
• Controlled lengths, generally ranging between 16 and 32 characters.
• Embedded business metadata such as dates or channels, for example: 20250615 + 3-bit Datacenter ID + 6-bit Machine Sequence + 4-bit Random Number.

Such scenarios frequently rely on segment-based allocation patterns (such as Meituan's Leaf segment pattern). Applications batch-request ID blocks from the database and cache them locally in memory, requesting fresh blocks only when exhausted. A double-buffer preloading mechanism balances both high performance and robust availability.

Scenario 3: Distributed Traceability

A single user request may traverse multiple components, including API gateways, order services, inventory services, and payment modules. To chain logs across the entire call graph, a globally unique traceId must be generated at the ingress point and propagated downstream via RPC frameworks or HTTP headers. Tracing systems like SkyWalking and Zipkin internally rely on high-efficiency ID generators. While traceId places little demand on monotonic incrementation, it remains sensitive to generation performance and length constraints, making UUIDs or Snowflake variants popular choices.

Scenario 4: Message Idempotency and Deduplication

Message queues may trigger duplicate consumption during delivery retries after failures. Producers generate a unique messageId when dispatching events, and consumers utilize this ID as an idempotent key:

1. Prior to consumption, query Redis or a deduplication ledger to check whether the messageId has already been processed.
2. If unprocessed, execute the business logic and write a deduplication record.
3. If already processed, directly acknowledge (ACK) and skip execution.

Additionally, anti-duplication tokens during flash sales or requestId validation filters are essentially applications of distributed IDs.

Scenario 5: Other Common Scenarios

• Cache Key Design: Embed business identifiers directly into cache keys, such as order:info:{orderId}, to simplify key tracking and batch eviction.
• File and Object Storage Naming: Rename uploaded files using distributed IDs to prevent overwriting and facilitate bucket partitioning by ID.
• Task Scheduling and Reconciliation: Generate execution batch numbers for scheduled jobs to facilitate monitoring, retries, and cross-system reconciliation.

Common Approaches and Selection Guidelines

When selecting a solution, follow these systematic steps:

1. Determine whether the ID will be exposed externally and if a monotonically increasing trend is required.
2. Evaluate QPS and latency budgets to decide whether local memory segment caching is necessary.
3. Prioritize mature, open-source solutions (such as Leaf, UidGenerator, or Tinyid) to avoid reinventing the wheel.
4. Design robust fallback mechanisms and alerting triggers for anomalies like clock drift or segment exhaustion.

Distributed IDs may appear straightforward, yet they permeate storage, messaging, and tracing layers alike. Establishing a unified ID specification during the early stages of system architecture design consistently minimizes future refactoring and reconciliation overhead.