Case study · Backend · Distributed Systems

SeatVault

Transaction-safe concurrency engine for high-contention reservations

Python

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 so the two layers never fight each other.

01The problem

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

02Approach

01Set explicit transaction boundaries so inventory deductions were atomic and rollback-safe.
02Serialized contention on hot seat keys with Redis distributed locks before touching the database.
03Backed the locks with PostgreSQL row-level locking so state stayed correct across split transactions.
04Modeled payment-style workflows as idempotent operations finalized in the background with Celery.

03Outcomes

Prevents overselling under concurrent requests through layered locking.
Idempotent background workflows close the double-book gap.
Distributed locks and row locks each do one defined job.

Back to all projects