Monotonic Counter Service

TechniqueIdentifiers and OrderingMidSeniorUpdated Nov 10, 2026

A dedicated service hands out strictly increasing 64-bit IDs. Simpler than Snowflake when you don't need offline generation.

When to Use Monotonic Counter Service

URL shortener short codes, order numbers, anywhere you need dense sequential IDs (not random). Trade-off: single point of contention unless you shard it.

In Practice

Bitly's hash-vs-counter hybrid. Internally, many systems pre-allocate ranges (e.g., 'this server reserves IDs 1M-2M') so the central service is hit infrequently.

How Monotonic Counter Service Comes Up in Interviews

Scenario

You're building a URL shortener and want dense, sequential short codes (not random hashes) so they stay compact. You can tolerate a central service that pre-allocates ID ranges to shorten-servers in 1M-ID chunks. Which technique?

A monotonic counter service hands out strictly increasing IDs, and pre-allocating ranges amortizes the central contention. Snowflake gives sparse, timestamp-prefixed IDs, bad for compact short codes.

Monotonic counters give you dense sequential IDs, which is what you want for compact base62 short codes, Snowflake's time-prefixed IDs would produce sparse codes that don't shorten well. The classic implementation is range allocation: a central service hands out blocks of IDs (e.g., 1M at a time) to shorten-servers, so the central contention is rare and a server crash only loses an unused block, not real data. Bitly and TinyURL use range-allocated counters; many internal Twitter/Facebook ID systems are variants. The tradeoff vs Snowflake: counters require some central coordination but produce dense IDs; Snowflake is fully decentralized but sparse.