How Tinyid Delivers High‑Performance Distributed ID Generation

Introduction

Tinyid is a Java‑based distributed ID generation system that extends the leaf‑segment algorithm. It provides globally unique 64‑bit numeric IDs that are trend‑increasing (not strictly monotonic) and can be non‑contiguous.

System Architecture

The service runs as a Tinyid server exposing two HTTP endpoints: nextId – returns the next ID for a given bizType. getNextSegmentId – returns a usable ID segment to the client.

An IdGeneratorFactory creates a dedicated IdGenerator per bizType, allowing new business types to be added without restarting the server.

Database Segment Algorithm

The DB table tiny_id_info stores biz_type, max_id, step and version. To allocate a segment:

Query the current max_id for the target biz_type.

Compute new_max_id = max_id + step.

Execute an optimistic‑lock update:

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 segment ( max_id, new_max_id] is allocated; otherwise retry.

Optimizations in Tinyid

Dual‑Segment Cache

Each server caches two segments: the current one for ID generation and a second one fetched asynchronously. This eliminates latency spikes when a segment is exhausted.

Multi‑DB Support

Multiple master databases can be configured. The server randomly selects a DB for segment acquisition. To avoid collisions, each DB can be assigned a distinct delta (step increment) and remainder (modulo). For example, one DB generates even IDs (delta=2, remainder=0) and another generates odd IDs (delta=2, remainder=1).

Tinyid Client SDK

The Java client fetches a segment once via getNextSegmentId and then generates IDs locally using AtomicLong.addAndGet(delta). This removes per‑request network overhead, raises QPS (up to >10 million when the segment size is large), and allows continued operation for a limited time if the server becomes unavailable.

Performance and Availability

Performance

HTTP access performance depends on server capacity and network latency.

Local generation via the client scales with segment size; larger step yields higher QPS.

Availability

Servers cache segments, so they can serve IDs briefly after a DB outage.

With multiple DBs configured, the service remains operational as long as at least one DB is alive.

The client can continue generating IDs from cached segments even if all servers are down.

Key Features

Globally unique 64‑bit IDs.

Trend‑increasing (not strictly monotonic).

Non‑contiguous ID space.

HTTP and Java client interfaces.

Batch segment acquisition.

Support for odd/even (or custom) sequences via delta and remainder.

Multi‑DB configuration for high availability.

Recommended Deployment

Deploy Tinyid servers across multiple data centers to improve availability; consider HTTP latency when selecting remote servers.

Prefer the Java client for high‑throughput local ID generation.

Configure at least two master databases; the service stays available if any one remains operational.

Final Architecture

Both HTTP and Java client interfaces are supported.

Each server caches two segments.

Segments are allocated atomically in the DB.

Multiple DBs provide redundancy.

An internal router selects a DB for each request.

Project Repository

https://github.com/didi/tinyid