Allo is a small storefront where pressing Reserve holds stock for ten minutes while you pay. I built it as a take-home assignment, and the part I cared about was the last unit: when 50 carts asked for one rug at the same moment, exactly one got it.
What it is
A catalogue of 106 products across four warehouses in Bengaluru, Delhi, Mumbai and Hyderabad. Reserve places a timed hold on the units. The customer confirms and the stock leaves the warehouse, cancels and it goes back, or does nothing and the hold expires on its own.
Why it matters
Overselling the last item is the classic checkout bug. The obvious code reads the stock, checks it's above zero, then writes the hold. Two requests that arrive together both read 1, both pass the check, and the shop has sold one rug twice. Most demos never notice, because they never get two requests at once.
What I built
I put the decision inside Postgres. reserve_units() is a PL/pgSQL function that locks the stock row with SELECT … FOR UPDATE, checks what's left, adds to reserved_units and inserts the hold, all in one transaction. A second caller waits on the lock, then sees 0 available and gets a 409. A CHECK (reserved_units <= total_units) constraint backs it up, so a bug somewhere else still can't oversell.
The Next.js route handlers stay thin: Zod checks the body, the database function does the work, and Postgres error codes map to HTTP statuses. The checkout page counts down the hold and listens for changes over Supabase Realtime, with a 5-second poll in case the socket drops. For fun, the home page plays its hero video as coloured ASCII on a canvas.
What was hard
Retries. A phone on a bad connection sends Reserve twice, and each request would take a unit. Both POST endpoints accept an Idempotency-Key. The first request claims the key with an insert that only one caller can win, then stores its response. A repeat gets that same response back instead of a second hold. A repeat with a different body gets a 409, and one that arrives while the first is still running waits up to 5 seconds, then gets a 425.
Expiry racing payment. A hold that's never confirmed has to come back even if nobody opens the page again. The first version used Vercel Cron, but the free plan only runs a cron once a day, which is useless for a 10-minute hold. I moved the sweep into Postgres with pg_cron, once a minute, using FOR UPDATE SKIP LOCKED so overlapping sweeps never block each other. Reading a reservation also expires it if its time is up. Confirm checks the clock inside the same lock that takes the stock, so a payment one second late fails cleanly.
The trade-off is a minute of slack: an expired hold can keep its unit for up to 60 seconds before the sweep returns it, unless someone reads it first. I accepted that over running a scheduler outside the database.
Where it landed
It's live at allo.abhashchakraborty.tech on Vercel and Supabase, with the database in Mumbai to sit close to its users. I wrote a race script that fires 50 reserves at the single rug in Mumbai and then releases the winner. Three runs in a row gave one 201 and 49 409s, with all 50 answered in 1.2 to 2.3 seconds.
There are no customer accounts yet, and the idempotency table is never pruned. Those are the next two things I'd add before it held real money.