Skip to main content

📘 PART V (i) — Data Correctness Across UI + DB (Idempotency, Concurrency, Reconciliation)

SECTION 0 — CORRECTNESS IS USER TRUST

Many “bugs” are correctness failures:

  • double submit

  • stale reads

  • phantom success

  • lost updates

Senior fullstack correctness means you design invariants and enforce them at boundaries.

SECTION 1 — EXACTLY-ONCE IS MOSTLY A LIE

Distributed systems are at-least-once.

So you need:

  • idempotency keys

  • dedupe tables

  • idempotent consumers

SECTION 2 — IDEMPOTENCY KEYS (WHERE USERS RETRY)

Use idempotency for:

  • checkout

  • uploads

  • “create” operations from flaky networks

Rules:

  • scope keys by user/tenant

  • store request hash

  • return the original result for repeats

SECTION 3 — OPTIMISTIC CONCURRENCY (STOP LOST UPDATES)

Pattern:

  • rows have version or updated_at

  • client sends If-Match / version

  • server rejects stale writes (409)

UI handles:

  • refresh and retry

  • conflict resolution where needed

SECTION 4 — AUDIT TRAILS (WHEN IT MUST BE PROVABLE)

If money, permissions, or critical data is involved:

  • append-only audit events

  • who/what/when

  • correlation IDs

SECTION 5 — USER-VISIBLE CORRECTNESS PATTERNS

  • disable submit buttons on action

  • show processing vs success explicitly

  • rehydrate state from server after reload

  • avoid optimistic UI for irreversible actions unless you have compensations

SECTION 6 — RECONCILIATION JOBS (THE SAFETY NET)

If external systems exist (payments, email providers, storage):

  • periodically reconcile internal vs external truth

  • auto-heal safe mismatches

  • alert on unsafe mismatches

SECTION 7 — EXERCISES

  1. Pick one create flow and define idempotency behavior.

  2. Add an optimistic concurrency contract to one update endpoint.

  3. Propose a reconciliation job for an external dependency.

🏁 END — DATA CORRECTNESS ACROSS UI + DB