Design a distributed unique ID generator: a service that hands out 64-bit identifiers to every other service in a large backend, so that rows, events, and messages get a globally unique key the moment they are created (think the ID stamped on a new chat message or order the instant it is written).

Operating context. Dozens of application services call this generator directly (embedded library) or over a thin RPC to mint IDs at row-creation time. Fleet-wide demand is roughly 50,000 IDs/sec sustained with bursts to 200,000/sec at peak, spread across two regions and many data-center racks. Consumers store IDs as a signed 64-bit integer and often sort or range-scan by them, so IDs should be roughly time-ordered (k-sorted), not random. The generator must keep minting even if a coordination store, a whole rack, or an entire region goes dark.

Out of scope. The databases that consume the IDs, authentication of callers, a human-readable slug/short-code layer on top, cross-service schema, and any analytics on ID usage. Assume a separate team owns those.

What to produce. A high-level design that names the ID minting components and the request flow from a caller to a minted ID. Lay out the 64-bit layout you choose (how many bits for time, node/worker identity, and per-tick sequence), how a node gets a unique worker identity without a human hand-assigning it, and your throughput ceiling per node. Then compare the main families — timestamp+node+sequence (snowflake-style), a central range/block allocator, and random 128-bit-truncated-to-64 UUIDs — and justify your pick against the ordering and single-point-of-failure requirements. Finally, address clock skew and backwards clock jumps: what a node does when its wall clock moves backward, and what ordering guarantee you actually promise (strict monotonic per node vs. k-sorted globally). Sketch the components and the mint flow; we will probe specifics at checkpoints.