sequencerlisted

# Sequencer Hand out identifiers that are unique across every node without a central bottleneck — and decide whether those IDs must also be *sortable* or *monotonic*. Getting this wrong shows up late and hard: collisions corrupt data, a single allocator caps write throughput, and IDs that leak a creation time or a sequential count expose business secrets and enable enumeration attacks. ## When to reach for this A system writes new records across multiple nodes and each needs a primary key (orders, messages, uploads, events). Reach for this when a single auto-increment column would serialize all writes, when IDs must be generated before a DB round trip (client-side, offline), or when records must be roughly time-ordered without a separate sort field. ## When NOT to A single relational node still comfortably serves the write load (→ `back-of-the-envelope`) — then a plain `BIGINT AUTO_INCREMENT`/`SERIAL` is the cheapest correct answer; do not build a distributed ID service for it (YAGNI). If a natural unique key already exists (email, ISBN, content hash), use it. Don't demand global monotonicity unless an invariant truly needs it — it is the most expensive property here and usually only *per-entity* ordering is required. ## Clarify first - **Generation point** — client/edge, app server, or database? (Decides whether a DB round trip per ID is acceptable.) - **Ordering need** — none, *time-sortable* (k-sorted is fine), or *strictly monotonic*? Per-entity or global? This is