Home Kitchen Marketplace Platform
A home-cooked food marketplace connecting home cooks directly with local customers, with real-time order tracking and background-job-driven fulfillment.
Web App · 2024 · Backend Engineer
Technology
- ASP.NET Core
- C#
- SQL Server
- Hangfire
- Redis
- SignalR
- React
Overview
Unlike a restaurant or a commercial cloud kitchen, this platform's entire model is home cooks — individuals cooking from their own kitchens and selling directly to nearby customers. That means the backend has to treat every seller as an independent, intermittently-available kitchen rather than a fixed commercial location with predictable capacity.
The API layer (ASP.NET Core) handles listings, ordering, and seller onboarding, while Hangfire drives the background workflows that can't block a request — order-status transitions, delivery-window scheduling, and notification dispatch. Redis caches high-read data (menu listings, seller availability) to keep the customer-facing experience fast without hammering SQL Server on every browse.
A React-based operations dashboard gives sellers and admins live visibility into incoming orders and fulfillment status, updated in real time over SignalR rather than polling.
Availability is the trickiest state to model here — a home cook might mark themselves available, then get three simultaneous orders that exceed what they can actually cook in the delivery window. The ordering flow has to reserve capacity at order time, not just check a boolean availability flag, or the platform ends up promising more meals than a seller can deliver.
The challenge
Problem: A simple available/unavailable toggle per seller doesn't prevent overselling — if three customers order from the same home cook within the same delivery window before any single order updates that seller's status, all three orders succeed even though the seller only has capacity for one.
Approach: Moved from a boolean availability flag to a capacity-reservation model: each listing carries a per-window capacity count, and placing an order atomically decrements that count (via a Hangfire job with a distributed lock, backed by Redis) rather than checking-then-writing in two separate steps that can race.
Result: Overselling incidents dropped to the cases that are genuinely the seller's fault (a last-minute capacity change), not a systemic race condition — and sellers get an honest, enforced view of how many orders they can actually commit to per delivery window.
Key features
- Seller (home cook) onboarding, listing, and availability management
- Capacity-reservation ordering that atomically decrements available slots per delivery window
- Order lifecycle and delivery-window scheduling via Hangfire background jobs
- Redis-backed caching and distributed locking for high-read, race-sensitive listing data
- Real-time order status updates to the React dashboard over SignalR
- Role-based access separating customer, home-cook, and admin workflows