Design real-time kitchen order fulfillment system

## Backend Engineering Challenge: Real-time order fulfillment Design and implement (conceptually) a **single-process, real-time backend system** for fulfilling food orders in a delivery-only kitchen. **Orders can be placed and picked up concurrently.** ### Order model Each order has: - **id**: short identifier (e.g., `e6bc2`) used at pickup time - **name**: food name - **temp**: ideal storage temperature: `hot`, `cold`, or `room` - **price**: dollars - **freshness**: duration (seconds) the food remains fresh **at its ideal temperature** **Freshness degradation rule** - If an order is **not** stored at its ideal temperature, it degrades **2× as quickly** as it would at ideal temperature. ### Storage devices - **Heater**: capacity 6, stores at `hot` - **Cooler**: capacity 6, stores at `cold` - **Shelf**: capacity 12, stores at `room` ### Placement logic (on order received) When a new order arrives: 1. The system “instantly cooks” it and must **store** it until pickup. 2. Try to store it at its **ideal** temperature (heater/cooler/shelf if room). 3. If the ideal option is full, place it on the **shelf**. 4. If the shelf is also full: - First, try to **move** an existing `hot`/`cold` order currently on the shelf into the **heater/cooler respectively**, if there is room. - If no such move is possible, **discard** one order currently on the shelf (choose a thoughtful discard criterion) to make room, then place the new order. ### Pickup logic - When an order is picked up, it must be removed **quickly without moving other orders around**. - If a pickup occurs and the order is not present, the kitchen takes **no action**. - If at pickup time the order’s age has exceeded its freshness duration (accounting for 2× degradation when not at ideal temperature), the order must be **discarded instead of picked up**. ### Action ledger Capture a time-ordered action ledger. Every action record includes at least: - **timestamp** - **order id** - **action**: `place`, `move`, `pickup`, `discard` - **target**: `heater`, `cooler`, or `shelf` Constraints: - For each order: first action is always **place**; last is **pickup** or **discard**. - Output actions to console in **human-readable** form as they occur. ### Execution harness (load test / simulator) Build a CLI harness that: - Fetches a list of orders from a challenge server. - Places orders at a configurable **rate** (default: 500 ms between orders). - Schedules each order’s pickup at a **random time** after placement within a closed interval (default: 4–8 seconds). - After all orders are processed (picked up or discarded), submits the action ledger to the server and exits. ### Non-functional requirements - **Concurrency:** placements and removals may happen concurrently; design should be safe for use beyond the harness. - **Efficiency:** discard selection when the shelf is full must be **better than O(n)** worst-case in the shelf size. - **Single process** (may be multi-threaded). Explain: - Your system architecture and concurrency approach. - Data structures enabling fast placement, lookup-by-id removal, and efficient shelf discard. - How you compute freshness under temperature changes. - Your discard criterion and why it’s reasonable.