Tinyid: A High‑Performance Distributed ID Generation System

Tinyid is a Java‑developed distributed ID generation system that implements a database segment algorithm (similar to Meituan Leaf) and extends it with multi‑master DB support and a Java client SDK, enabling local ID generation for higher performance and availability; it is used by Didi’s customer‑service department to generate billions of IDs per day.

The system exposes two HTTP interfaces, nextId (to obtain the next ID) and getNextSegmentId (to fetch the next usable segment). Internally, an IdGenerator interface is created by an IdGeneratorFactory (with server and client variants), and a CachedIdGenerator holds the current and next segments, producing IDs via AtomicLong.addAndGet(delta).

Performance and availability : HTTP access performance depends on the server and network, while the Java client generates IDs locally; with sufficiently large segments, QPS can exceed 10 million. Availability is ensured by DB caching—if a DB fails, cached segments keep the service alive, and with multiple DBs only one needs to be up.

Key features include globally unique long IDs, trend‑increasing (not strictly monotonic) IDs, non‑continuous IDs, HTTP and Java client access, batch ID retrieval, support for custom sequences (e.g., odd numbers), and multi‑DB configuration without a single point of failure.

Recommended deployment : Deploy multiple Tinyid‑server instances across data centers; use the Tinyid‑client for local generation to reduce server load; configure at least two databases so that the service remains available as long as one DB is operational.

Fundamental requirements for an ID generation system are global uniqueness, high performance (preferably local generation), high availability (approaching 100 %), and simplicity of use.

Database segment algorithm : The DB stores records with fields biz_type, max_id, step, and version. To acquire a segment, the client performs the following steps:

Query the current max_id:

SELECT id, biz_type, max_id, step, version FROM tiny_id_info WHERE biz_type='test';

Calculate new_max_id = max_id + step.

Update the DB atomically:

UPDATE tiny_id_info SET max_id = #{new_max_id}, version = version+1 WHERE id = #{id} AND max_id = #{max_id} AND version = #{version};

If the update succeeds, the usable segment is (max_id, new_max_id]; otherwise retry.

The simple architecture routes HTTP requests through a load balancer to any Tinyid‑server, which draws IDs from its cached segments; if a segment is exhausted, a new one is fetched from the DB. This design, however, has drawbacks such as DB single‑point bottlenecks and network overhead.

Optimizations include double‑segment caching to pre‑load the next segment, multi‑DB support with even/odd ID distribution (using additional fields delta and remainder), and the Tinyid‑client that obtains segments once and then generates IDs locally, greatly improving throughput and resilience.

The final architecture combines HTTP and client modes, dual‑segment caching on the server, atomic DB‑generated segments, multi‑DB selection via an internal router, and optional client‑side generation.

Project repository: https://github.com/didi/tinyid