[Submission] GPU Drop Reserver

[logesh45]

Project link

https://github.com/logesh45/GPU-Drop-Reserver

Language

Python

Short description (max 256 chars)

Temporal demo for flash sales: durable timers for checkout deadlines, signals when the buyer finishes, and compensation that puts stock back if they don’t. FastAPI + React UI—same idea as GPU drops or timed ticket holds, without fragile cron-only hacks.

Long Description

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.

Author(s)

Logesh Rajendran - Capital One

[github-actions]

Hi, I'm ZiggyBot! 🤖 Here's my pre-evaluation of this submission:

---

Criterion	Assessment
Useful to Temporal users	⚠️ Unclear — The concept (flash sale reservations with durable timers, signals, and compensation) is genuinely useful, but without repository content to verify, the actual implementation quality can't be assessed.
Benefits clearly explained	❌ No — There is no README in the repository to explain the project's benefits or how it demonstrates Temporal patterns.
OSI Approved License	❌ No — No license file was detected in the repository.
README with working instructions	❌ No — No README was found, so there are no setup or usage instructions available.

Overall: Does not meet criteria ❌

Notes:

• The submission description sounds promising! A flash-sale/GPU-drop reservation system is a fantastic use case for demonstrating Temporal's durable timers, signals for buyer completion, and compensation logic for restocking. These are patterns many developers struggle with when building time-sensitive reservation systems.
• Unfortunately, the repository appears to be empty or inaccessible — no README, no detected license, and no code could be fetched for review.
• The project may be a work-in-progress or the repository visibility settings may need adjustment.

Suggested questions for submitter:

• Is the repository public and populated with code? We weren't able to fetch any content from the provided URL.
• Could you add a README explaining how to run the FastAPI backend and React UI, along with the Temporal Worker setup?
• Would you be able to add an OSI-approved license (MIT is a great choice for demos!) so the community can confidently use and learn from your code?

Teaching moment:

Based on the submission description, this project would demonstrate a lovely pattern: using durable timers for checkout deadlines combined with signals for buyer completion and compensation activities for restocking. This is exactly the kind of "saga-like" reservation flow where Temporal shines compared to fragile cron-based approaches. However, without access to the actual code, we can't verify or highlight a concrete implementation example. Once the repository is populated, we'd love to see how the timer-signal-compensation trio is orchestrated!

---

---

ZiggyBot is an AI pre-screener based on Temporal's community mascot Ziggy. Final decisions are made by the community team.

Reviewer: Check the box below to generate a Contentful-ready long description for this submission.

• Generate long description if needed

[github-actions]

Hi, I'm ZiggyBot! 🤖 Here's my pre-evaluation of this submission:

---

Criterion	Assessment
Useful to Temporal users	⚠️ Unclear — The concept described (durable timers, signals, compensation for flash sales) sounds genuinely useful, but without code or documentation to verify, the actual implementation cannot be assessed.
Benefits clearly explained	❌ No — No README or documentation exists in the repository to explain the project's benefits or architecture.
OSI Approved License	❌ No — No license file was detected in the repository.
README with working instructions	❌ No — No README was found; there are no setup instructions, usage examples, or documentation of any kind.

Overall: Does not meet criteria ❌

Notes:

• The submission description paints an exciting picture of a Temporal demo showcasing durable timers for checkout deadlines, signals for buyer completion, and compensation logic for stock return—all patterns that would genuinely help the community understand Temporal's value for e-commerce scenarios!
• Unfortunately, the repository appears to be empty or inaccessible. GitHub shows no README, no detected license, and zero stars, suggesting this may be a placeholder or work-in-progress.
• The described stack (FastAPI + React UI) combined with Temporal for flash sale reservation is a compelling use case that we'd love to see completed!

Suggested questions for submitter:

• Is this repository still being set up? We'd love to see the code when it's ready!
• Could you add a README explaining how to run the project locally, including any dependencies for the FastAPI backend and React frontend?
• Would you be able to add an OSI-approved license (MIT is our recommendation) to the repository?
• Could you share a brief architecture diagram or description showing how Workflows, Activities, Signals, and Timers interact in your flash sale flow?

Teaching moment:

Based on the submission description, this project would demonstrate Saga-style compensation with durable timers—a powerful pattern where a Workflow holds inventory with a timer, waits for a Signal indicating payment completion, and automatically runs compensation (restocking) if the timer fires first. This is a fantastic real-world example of why Temporal's guarantees matter: without durable execution, a crashed process during checkout could permanently lock inventory. Unfortunately, without access to the actual code, we cannot point to a specific implementation. We encourage the submitter to complete this project—it would make an excellent teaching resource!

---

---

ZiggyBot is an AI pre-screener based on Temporal's community mascot Ziggy. Final decisions are made by the community team.

Reviewer: Check the box below to generate a Contentful-ready long description for this submission.

• Generate long description if needed

[logesh45]

@zi Try again

[Shy]

@evaluate

[github-actions]

Hi, I'm ZiggyBot! 🤖 Here's my pre-evaluation of this submission:

---

Criterion	Assessment
Useful to Temporal users	✅ Yes — Demonstrates a practical reservation/hold pattern with durable timers and compensation logic that's directly applicable to e-commerce, ticketing, and flash sale scenarios.
Benefits clearly explained	✅ Yes — The README clearly explains the problem (checkout timer ambiguity) and how Temporal's durable timers, signals, and compensation solve it with a "clearer contract."
OSI Approved License	❌ No — No license file was detected by GitHub, which means the project is technically "all rights reserved" and cannot be safely used or redistributed.
README with working instructions	✅ Yes — Provides multiple ways to run the demo (Honcho single-terminal, three-terminal split, CLI demos) with clear prerequisites and commands.

Overall: Needs review ⚠️

Notes:

• This is a well-structured educational demo with a relatable real-world scenario (GPU drops, ticket holds) that many developers will recognize.
• The workflow code is clean and demonstrates proper use of workflow.wait_condition with timeout instead of asyncio.wait_for (with a helpful comment explaining why!).
• The compensation pattern (restore inventory on timeout) is a textbook Saga example that's valuable for teaching.
• The project includes tests (make test), which is a nice quality signal.
• The missing license is the only blocking issue — this is an easy fix!

Suggested questions for submitter:

• Would you be willing to add an MIT (or other OSI-approved) license to the repository? This is required for Code Exchange inclusion.
• The README mentions an INSTRUCTIONS.md file for detailed steps — could you confirm this file exists and is complete?

Teaching moment:

This project beautifully demonstrates the durable timer + signal + compensation pattern using workflow.wait_condition with a timeout. Instead of fragile cron jobs or in-memory timers that die with server restarts, the workflow waits durably for either a checkout signal OR a timeout — and then runs the appropriate compensation activity (restore_inventory) if the customer didn't complete in time. The comment explaining why workflow.wait_condition is preferred over asyncio.wait_for ("asyncio.wait_for does not advance correctly in the workflow sandbox") is a great teaching moment about Temporal's deterministic execution model.
View in source ↗

---

---

ZiggyBot is an AI pre-screener based on Temporal's community mascot Ziggy. Final decisions are made by the community team.

Reviewer: Check the box below to generate a Contentful-ready long description for this submission.

• Generate long description if needed

[logesh45]

@evaluate

[github-actions]

Hi, I'm ZiggyBot! 🤖 Here's my pre-evaluation of this submission:

---

Criterion	Assessment
Useful to Temporal users	✅ Yes — Demonstrates a practical reservation/timeout/compensation pattern that directly applies to e-commerce, ticketing, and flash sale scenarios many developers encounter.
Benefits clearly explained	✅ Yes — The README clearly articulates the problem (ambiguous checkout timeouts, ghost stock) and explains how Temporal's durable timers and compensation logic solve it.
OSI Approved License	✅ Yes — Licensed under MIT, a well-recognized OSI-approved license.
README with working instructions	✅ Yes — Provides comprehensive setup instructions with multiple options (Honcho single-terminal, three-terminal, CLI demos), prerequisites, and even screenshot documentation.

Overall: Looks good ✅

Notes:

• This is a well-crafted educational demo that nails a common real-world use case. The "checkout story" framing makes the problem immediately relatable.
• Excellent documentation including screenshots of both the browser UI and Temporal Web UI showing workflow history for both success and timeout paths.
• The project thoughtfully includes both happy path and compensation path demonstrations via make demo-timeout and make demo-checkout.
• Clean separation between workflow orchestration and activity implementations.
• The disclaimer about trademarks and educational purpose is a nice touch for a demo project.

Suggested questions for submitter:

• None — the submission is thorough and the code demonstrates the stated patterns clearly.

Teaching moment:

This project showcases an excellent use of workflow.wait_condition() with a timeout to implement a checkout deadline—a pattern that's far more reliable than traditional cron-based or in-memory timers. The workflow waits for a userCheckedOut signal, and if the timeout fires first, it automatically triggers compensation activities (restore_inventory, send_cart_expired_email). This "timer + signal race" pattern is a Temporal sweet spot: the timer is durable across failures, and the compensation logic is guaranteed to run exactly once.
View in source ↗

---

---

ZiggyBot is an AI pre-screener based on Temporal's community mascot Ziggy. Final decisions are made by the community team.

Reviewer: Check the box below to generate a Contentful-ready long description for this submission.

• Generate long description if needed