Enforcing Constraints: Consensus or Apologize-and-Compensate? Diagram

Concurrent requests carrying the same value force a decision: accept one, reject the rest — that decision is consensus, usually one leader per shard
Scale it by sharding on the constrained value (request ID, hash of username) so conflicting writes always land on the same shard
Asynchronous multi-leader replication is ruled out: leaders would accept conflicting writes concurrently; rejecting violations immediately makes synchronous coordination unavoidable

Many businesses already accept violations: overbooked seats, oversold stock, overdrawn accounts — fixed with refunds, upgrades, restocking, or overdraft fees
The apology workflow must exist anyway (a forklift can flatten warehouse stock), so a hard constraint is often unnecessary overhead
Write optimistically and check after the fact with a compensating transaction; only validate before actions that are expensive or impossible to undo

Strong integrity without consensus: integrity is not timeliness — a temporarily violated constraint can be repaired later as long as nothing is lost
Without synchronous coordination, regions can run as independent multi-leader datacenters with asynchronous replication and keep serving through partitions
Introduce synchronous coordination only where strictness is truly needed; coordination buys fewer inconsistency apologies but costs performance and availability