Distributed ID Generator

Use explicit timestamp/worker/sequence fields with serialized per-worker generation and conservative issuance bounds. Uniqueness depends on exclusive worker identity ownership and safe persisted restart state.

1. Choose an epoch and millisecond ticks. A 41/10/12 layout offers 1024 worker slots and 4096 IDs per worker per tick within the timestamp lifetime. Return IDs as decimal strings to clients that cannot represent 64-bit integers exactly.
2. Provision worker IDs exclusively through a registry. This design does not automatically reassign an uncertain worker slot: drain or otherwise prevent the old issuer from running before reuse. Registry leases alone are insufficient to fence returned IDs.
3. Persist a reserved timestamp high-water bound before issuing inside that window. After restart, refuse issuance until actual safe time is beyond the previous reserved window; reserve another window durably. A registry/store failure blocks new reservation, not permission to reuse old IDs.
4. Under a per-worker lock, clamp no timestamp backward: wait with a deadline or fail on regression. Reset sequence only on a new tick; on exhaustion wait for a safe tick. Reject timestamps outside the bit lifetime.

• Clock regression never reuses a timestamp/worker/sequence tuple.
• Sequence exhaustion cannot wrap inside a tick.
• Restart waits beyond the previously reserved window before issuing.
• A worker slot cannot be assigned to two unfenced issuers; integer serialization preserves all bits.

Trade-offs to explain

• Conservative identity reuse reduces availability but prevents split-brain issuance. A UUID-style scheme avoids the worker registry with a different size/ordering contract.
• Reserved time windows amortize durable writes but increase recovery wait after a crash.
• Clock-sorted IDs expose approximate creation time and do not replace a transaction sequence or consensus log.