Case study — Backend · Distributed Systems

SeatVault

Transaction-safe concurrency engine for high-contention reservations

FastAPI

PostgreSQL

Redis

Celery

Docker

How it works

one reservation · layered locking

live

Client request

POST /reserve · with idempotency key

Redis distributed lock

SET key NX EX — hold the seat key

PostgreSQL row lock

SELECT … FOR UPDATE on the seat row

Update inventory

atomic UPDATE inside the transaction

outcome

Commit

release lock → done

Rollback

release lock → retry

Get the distributed lock first, then the row lock. Commit atomically, release in reverse order — the two layers never fight each other.

01The problem

Reservations under flash-sale load collapse into overselling and double-bookings. The core difficulty is keeping inventory internally consistent while many requests race for the same seat at once.

02Approach

01Designed explicit transaction boundaries so inventory deductions were atomic and rollback-safe.
02Used Redis distributed locks to serialize contention on hot seat keys before touching the database.
03Backed them with PostgreSQL row-level locks so state stayed correct even under split transactions.
04Implemented idempotent payment-style workflows and background processing with Celery for reliable finalization.

03Outcomes

Prevents overselling under concurrent requests via layered locking.
Idempotency + background wrkers close the double-charge / double-book gap.
Squates distributed-locking and row-locking responsibilities deliberately.

Back to all projects