GPU Drop Reserver

Flash Sale Cart Reserver#

Educational project that shows how Temporal handles a common high-pressure e‑commerce pattern: reserving scarce inventory, giving the shopper a fixed window to pay, then either completing the sale or releasing the hold.

What it demonstrates (why Temporal users care)#

• Durable timers — The “finish checkout by…” deadline survives process restarts; you’re not wiring your own scheduler.
• Signals — e.g. userCheckedOut when the buyer completes payment, so the workflow can finish the happy path.
• Compensation / saga — If the timer fires first, the workflow runs restore inventory so the unit goes back on sale—no orphaned reservations.
• Task queue + worker — A realistic split: API starts workflows; a worker (flash-sale-cart) runs them against Temporal’s persistence (Postgres in Docker), not your app’s in-memory state.

Compared to cron jobs + ad‑hoc DB flags, this makes the whole reservation lifecycle one durable program: easier to reason about, replay, and extend.

What’s in the repo#

Piece	Role
Docker Compose	Temporal server, Web UI, Postgres
Python worker	Polls the flash-sale-cart queue
Workflow	Reserve → wait (timer) → checkout or rollback
Activities	SQLite reserve / restore, stub order + email
FastAPI	Backend for the demo UI (port 8787)
Vite + React	Demo frontend (proxies /api)

Inventory is SQLite locally so the demo stays self-contained; Temporal still uses Postgres as designed.

Problems it maps to#

• Flash sales / drops — GPUs, consoles, limited SKUs.
• Ticketing — Hold a seat; pay within N minutes or it returns to inventory.
• Any “soft lock” — Time-bounded reservation with automatic cleanup.

Run it (summary)#

• make up — Temporal stack
• make honcho — worker + API + frontend (per Procfile / Makefile)

Default demo SKU is illustrative (founders-gpu-fe); configurable via env/CLI.