---
title: "Generate unique IDs with database ticket servers"
description: "Use dedicated database sequences to issue globally unique IDs, then reason about batching, failover, and ordering tradeoffs."
canonical_url: "https://fanout.sh/system/archive/database-ticket-servers"
md_url: "https://fanout.sh/system/archive/database-ticket-servers.md"
access: "public"
---

# Generate unique IDs with database ticket servers

Use dedicated database sequences to issue globally unique IDs, then reason about batching, failover, and ordering tradeoffs.

## Public overview

Database Ticket Servers

A database ticket server is a small dedicated database used only to issue unique IDs.

Use the database's auto-increment behavior as the atomic sequence generator, then use the returned value as an ID in other databases.

Flickr used dedicated MySQL ticket servers with one-row tables. To avoid one ticket server becoming the only authority, they split the ID space:

This preserves uniqueness without cross-server replication.

database auto-increment is atomic, generated IDs are compact, operational model is familiar, sequence state persists through restart, no per-app worker-ID assignment needed.

network call to get an ID, dedicated database service to operate, availability depends on ticket service health, strict global monotonicity can be weakened when multiple ticket servers drift, high write throughput can pressure the ticket DB.

Batch Allocation Variant

Instead of one ID per call, allocate ranges:

This reduces sequencer load at the cost of wasted IDs if a server dies before using its range.

Requirement Fit --- --- Globally unique numeric IDs Strong. Compact database keys Strong. Strict creation order across all IDs Only with one authority. Offline ID generation Poor. Very high write throughput Needs batching or another design.

Ticket servers are attractive because they are simple. They use database correctness instead of a new distributed consensus system. That simplicity is valuable when ID generation is not the main scaling bottleneck.

Ticket server outage prevents new object creation. ID allocation becomes a latency dependency on every write path. Multi-ticket setup loses strict global ordering. Batch allocation wastes ranges after process crashes. Sequence exhaustion is ignored until the type limit is near. Application code assumes IDs reveal exact creation time or shard.

The failure mode is different from UUIDs. UUID generation can continue during network partitions, but it has larger keys and weaker locality. Ticket servers give compact ordered IDs but introduce a service dependency.

Run ticket servers as critical infrastructure. Monitor allocation QPS, latency, error rate, sequence headroom, replication health, and disk durability. Keep the schema tiny and avoid sharing this database with product tables.

If using two servers with odd/even IDs, document which server owns which increment and offset. A misconfigured replacement can issue duplicate IDs.

---
This representation contains public Fanout content only. Protected Pro lessons, account data, billing, checkout, and pricing are not included.

Browse the public content map: https://fanout.sh/sitemap.md