Backend concept

Transactions & Consistency

Atomic writes, isolation anomalies, locks, uniqueness constraints, and invariant protection.

Why this matters

Correct backend systems protect business invariants even when requests race.

Practice deciding when a lock, constraint, transaction, or idempotency key is required.

0 active misses 0 reviewed 0 games completed

No local review items for this concept yet.

Identify common concurrency anomalies such as lost updates, phantoms, and partial writes.
Choose between row locks, atomic updates, constraints, serializable isolation, and optimistic concurrency.
Explain why application-level checks are not enough for many shared data invariants.
Decide when operations need idempotency keys and stored results.
Handle retries, in-progress operations, and reused keys with different payloads.
Combine idempotency with database constraints and transactional consistency.

Checking a condition in application code and writing later without a lock or constraint.
Using last-write-wins where users expect conflict detection.
Assuming READ COMMITTED prevents every race.
Adding broad table locks where row locks, constraints, or snapshots would be safer.
Creating a second payment, order, or import because a retry arrived later.
Allowing the same idempotency key to mean different request bodies.

Start with the first game, then use local review history to revisit missed decisions.

Databases Advanced

Defend database invariants from concurrent requests by choosing transactions, locks, constraints, snapshot reads, and optimistic concurrency.

Time: 7-10 minutes
Concept: Database transactions, isolation anomalies, locks, and invariant protection

Reliability Intermediate

Diagnose retry scenarios and choose safe idempotency behavior for payments, emails, imports, orders, PUT updates, and scarce inventory.

Databases Intermediate

Choose the best database index for simplified schemas and queries while learning full scans, covering indexes, sort avoidance, and composite order.