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.