How these systems work.

Four diagrams from projects I’ve built. They cover missed sync records, uncertain payouts, multiplayer scoring, and database deadlocks.

Each diagram highlights an invariant: a condition the implementation needs to preserve.

erp-sync --keyset-drain

§V · FIG.01

FIG. 01

Syncing every ERP record

The ERP records changes with timestamps rounded to the minute. Advancing the cursor after a full 1,000-row page could skip other records from that same minute.

watermark = MINUTE-resolution timestamp>1000 rows in one minute → overflow stranded silently

composite keyset cursor(timestamp, primary-key)
drain a saturated minutepage-by-page
restart at a 1-minute overlap floorre-reads in-place edits
idempotent upsert

Never advance the watermark unless accepted + rejected == rows_sent. Every sent row must be accounted for.

payouts --exactly-once

§V · FIG.02

FIG. 02

Handling uncertain payouts

A payout request can time out after money has moved. The response alone doesn’t tell us whether it is safe to try again.

provably rejected

DEFINITIVE failuremoney never moved

RELEASE fundssafe to re-claim

might have succeeded

AMBIGUOUSkeep PENDING

reconcilewebhook · status-check · admin

resolvepaid|failed

Release funds only on a provable failure. Keep an uncertain transfer pending until its status is confirmed.

realtime --server-authoritative

§V · FIG.03

FIG. 03

Multiplayer scoring6 → 100+ players

The server checks answers and assigns scores. During a live question, clients receive neither the answer key nor permission to set their own score.

token

client requests join
gateauth + payment + room membership
scoped tokensubscribe / presence only

the correct answer is never sent to clients during a live question

answer

answer submit
atomic compare-and-setfirst-answer-wins guard
server-authoritative scoring
broadcast6 → 100+ subscribers

round

round advance
coordinator electiondeterministic leader + liveness takeover
idempotent phase claim

The server calculates scores and withholds the answer key during live questions. Six-player rooms can broadcast updates to more than 100 subscribers.

locks --one-global-order

§V · FIG.04

FIG. 04

Consistent lock orderingLogistics · Postgres

Two payment operations can deadlock when they lock the same rows in opposite orders. Postgres aborts one transaction with 40P01.

flow Abillspayments

flow Bpaymentsbills

each holds what the other wants → 40P01

billssorted by bill number
then the payment row

unlocked discovery readlock in global orderrevalidate under lock

A single global lock ordering across every money path, so the cycle that caused 40P01 cannot form.

For the business context and the rest of each project, see the case studies.