Build a globally-unique, k-sortable ID generator that every write in the platform depends on. The hard part isn't picking a bit layout — Twitter Snowflake's 41/10/12 has been right since 2010 — it's that ID generation is the single highest-leverage piece of state in the entire infrastructure. A 99.9% ID service drags every dependent service to 99.9%. A worker-id collision silently corrupts data at rest until a downstream consumer notices a primary-key violation hours later. A leap-second smear bug rewinds a host's clock and the next ID issued duplicates one already in storage. The canonical here serves three caller classes side-by-side because that is what production teams actually run: (1) **UUIDv7 in-process** for ~90% of services that can take a 128-bit ID — zero network calls, ~2 µs per ID, immune to coordinator outages; (2) **Snowflake RPC fallback** for legacy callers that need 64-bit BIGINTs, sortable cursors, or polyglot interop; (3) **Leaf-segment range allocator** for human-facing sequential IDs (invoice numbers, order numbers) where customers expect short monotonic integers. The architecture's job is to make all three correct under the failure modes that historically cause silent dup-ID incidents — clock rewind, worker-id collision, segment-failover burn — and to detect any dup that does slip through within the next audit window. This is a **single-region active-active** design with cross-region DR for the segment table. Multi-region active-active for ID generation is doable (per-region DC-id bits in Snowflake, per-region etcd cluster) but adds coordination cost without buying meaningful availability over the in-process default for the 90% of callers who don't need RPC at all.