Quorum is an incident command plane built on Amazon Aurora DSQL. The failover story lives in another post. This one is about a narrower question that turned out to be the foundation: when several responders write to the same incident at the same moment, across regions, during the worst minutes of an outage, how do you guarantee the record never forks into two conflicting truths.
The answer is two design choices that are really one choice seen from two angles: event sourcing, and DSQL's optimistic concurrency control.
The data model is append-only
Quorum is event-sourced across four tables. Every state change is an immutable event appended to a log, not an in-place update. The current state of an incident is a fold over its events. There is no UPDATE incidents SET status = ...; there is an acknowledged event, a note event, a resolved event, and the status you render is computed from them.
The event's UUID is its primary key and its idempotency key at the same time. A retried write carrying the same UUID cannot double-apply: the insert collides on the primary key and becomes a no-op. That property sounds minor until you remember what kind of system this is. A tool designed to survive network failure retries writes constantly, and "the responder tapped resolve twice because the first response was slow" must not produce two resolutions.
Append-only also suits the domain directly. For an incident system the audit trail is the product, not a side effect. "Who acknowledged this, at what time, and what did the timeline look like at 02:14" is a first-class question for the post-incident review and a compliance requirement in regulated environments. Event sourcing gives you that for free. It also gives DSQL a write pattern it likes, which matters more than you would expect.
The stack, briefly
TypeScript end to end. .
Optimistic concurrency, the core
DSQL does not take row locks. A transaction reads a consistent snapshot, does its work, and the conflict check happens at commit time. When two transactions modify the same data, the one with the earliest commit time wins and the other receives a serialization error, the PostgreSQL SQLSTATE 40001 (DSQL also surfaces its own OC000 and OC001 codes), which the application is expected to retry. No locks are held for the duration of a transaction, and there are no deadlocks, ever. This is documented in is the source worth reading.
Think about what a pessimistic, lock-based database has to do when it loses a region or a node mid-flight: there are locks held by transactions that were in progress when the failure hit, and that state has to be reconciled before the survivor can safely proceed. A lock-free system has no lock state to strand. Brooker is concrete about why this matters in DSQL: the component that orders commits, the adjudicator, holds no durable state, so when a region drops away the adjudicator leader moves to the surviving majority side, which already knows every committed transaction and so has everything it needs to recreate that state. There are no stranded locks to untangle, because there were never any locks.
That is the same mechanism that keeps Quorum's incident record from forking. When two responders contend on the same record, optimistic concurrency guarantees one commits and the other retries against the now-updated state. There is one truth. The property that lets the database survive a region loss and the property that keeps the incident record consistent under contention are not two features bolted together. They are one design choice.
You can watch it
The Reliability surface on the live deployment runs this in front of you. The no-split-brain demo races two writers at the same record and shows that the record never diverges. A burst test fires fifty concurrent writes; they all commit durably, with conflicts resolved by retry rather than lost. Every number on that page is measured on the click, not canned, so the latency you see is the latency the database returned for that request. Run it yourself: . The source, including the full architecture decision log, is on GitHub at https://github.com/hocmemini/quorum.
This post was created for the purposes of entering the H0 "Hack the Zero Stack" hackathon. It is one of three: a companion post covers [the failover layer and what the chaos demo proves], and a third covers [how the system was built by directing an AI agent under an append-only decision log]. #H0Hackathon
SOCIAL SHARE CARD GENERATOR