🔧 Programmierung 🕛 vor 2 Monaten 4 Min Lesezeit
0

A Jepsen-lite witness: prove "sold once" from committed history, not app hope

↗ Quelle (dev.to)
🗣️ Stimme:
📑 Inhaltsübersicht

When you claim a system is correct under concurrency, the dangerous move is to ask the application whether it was correct. The app is the least trustworthy witness in the building: it reports what it intended, after retries, across a network that drops and reorders. If you count "how many purchase calls returned confirmed", you are grading the system on its own self-report. That's how demos lie without anyone meaning to lie.



WorldSeat — a worldwide ticket on-sale built for AWS's Hack the Zero Stack — answers the correctness question with an external checker instead. I call it the Consistency Witness, and it's deliberately Jepsen-shaped: it ignores what the app said and reconstructs the truth from the committed history in the database.






The invariant, reduced to something checkable



Full linearizability checking is expensive. But the safety property a ticketing system actually needs collapses to one tiny invariant:




For one physical seat, there is at most one successful exclusive acquisition.




That's it. If two different buyers each hold a confirmed claim to seat A1, the history is not linearizable — there is no single global order of operations in which both acquisitions of the same exclusive resource succeed. You don't need a full happens-before graph to detect it; you need to count confirmed acquisitions per seat.



So the witness does exactly that, against committed state:




CODE
// DSQL: read the committed op_log directly
SELECT seat_id, count(*)::int AS confirmed
FROM op_log
WHERE outcome = 'confirmed'
GROUP BY seat_id;

// then, for every seat:
doubleSells = Σ max(0, confirmed - 1)
linearizable = (doubleSells === 0)






doubleSells is the number of people who hold a ticket they shouldn't. Zero means every seat was acquired by at most one buyer; anything above zero names the seats with multiple holders.



For the DynamoDB foil the source changes but the logic doesn't: the witness reads the append-only sales ledger with ConsistentRead: true from both regional replicas and unions them, de-duplicated by a globally-unique sale_id, so cross-region replication lag can't make a double-sell disappear by simply not having arrived yet.






Why read the ledger, not the seats table



This is the subtle part, and it's where eventual consistency hides its damage. On the naive DynamoDB backend, the seats table eventually converges to a single owner per seat — last-writer-wins overwrites the others. If you inspected only the seats table, the system would look fine: one seat, one owner. The oversell is invisible there.



The truth lives in the append-only ledger, which records every confirmation as it was issued. Three buyers were each told "you got A1" and each got a confirmation code; LWW later picked one to display, but three people are walking to the same chair. The witness reads the ledger precisely because it's the one place the system can't quietly forget what it promised.






Reconciling two different measurements



WorldSeat shows two numbers that look like they should match but measure different scopes, and reconciling them honestly was a design point:




  • The Break-it scoreboard measures the single seat the last burst targeted.

  • The Witness sums double-sells across the whole floor (every seat with history).



If you've run several bursts on different seats, the floor-wide total is legitimately larger than the last seat's count. Rather than paper over that, the witness accepts an optional ?seat= focus so it can report the scope-matched number for the targeted seat and the floor-wide total side by side — and the UI explicitly prints "✓ reconciled" only when scoreboard oversold equals the witness's focus count for that seat. Matching numbers you didn't engineer to match is the difference between a checker and a prop.






The payoff



Because the verdict is computed from committed history every time you ask, it's not a stored boolean you can fake. On Aurora DSQL it reads Linearizable ✓ after sixty concurrent buyers hit one seat across two regions. On DynamoDB Global Tables running the same code it reads Violated ✗ and names the over-sold seats. The checker is the same; only the database's consistency model changed the verdict.



See it live: https://worldseat.vercel.app — press Break it, then read the Witness.

Vollständiger Original-Artikel
Den kompletten Beitrag mit allen Details direkt auf dev.to lesen.
↗ Original-Artikel auf dev.to lesen
Wie bewertest du diesen Beitrag?
1 Klick Feedback
Teilen mit Netzwerk & Team:

Community-Analysen & Experten-Meinungen 0

Verfasse deine eigene Analyse, teile Workarounds oder diskutiere diesen Vorfall im Blog.
Noch keine Community-Analyse verfasst. Markiere einen Textabschnitt oder klicke oben auf Eigene Analyse verfassen“!
Community Pulse: Relevanz-Einschätzung
1 Klick Experten-Votum
🔴 Akute Relevanz 0%
🟡 In Evaluierung 0%
🟢 Keine Auswirkung 0%
Spannende Innovation 0%
Verwandte Story-Cluster & Quellen (Vektor-KI)
Port 8095 Engine
1 Quelle
Staatliche Hacker treiben laut Chainalysis einen Anstieg von 420 % bei Onchain-Malware voran
1 Quelle
Chinesische KI-Modelle verursachen Anstieg der auf der Blockchain platzierten Malware ...
1 Quelle
Millionen-Lösegeld nach Hacker-Angriff auf Revolut: Was Kunden jetzt wissen müssen
Ähnliche Beiträge
🔍 Verwandte News

Auch interessante Nachrichten A Jepsen-lite witness: prove "sold once" from committed history, not app hope

Thematisch verwandte Begriffe: Jepsenlite, witness, prove, sold · 6 Treffer

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...