Real-Time Kitchen Order Fulfillment System Design

Design and conceptually implement a single-process, real-time backend system for managing food orders in a delivery-only kitchen. The system must handle concurrent order placements and pickups.

Order Model

Each order is defined by:

• ID: A short identifier (e.g., e6bc2) used for pickup.
• Name: The food item's name.
• Temperature: The ideal storage temperature: hot, cold, or room.
• Price: The order's price in dollars.
• Freshness: The duration (in seconds) an order remains fresh when stored at its ideal temperature.

Freshness Degradation Rule: If an order is not stored at its ideal temperature, its freshness degrades at twice the normal rate.

Storage Devices

The kitchen has three storage devices with specific capacities and temperature controls:

• Heater: Capacity 6, maintains hot temperature.
• Cooler: Capacity 6, maintains cold temperature.
• Shelf: Capacity 12, maintains room temperature.

Placement Logic (On Order Received)

When a new order arrives:

1. The system simulates "instant cooking" and must immediately store the order until pickup.
2. Attempt to store the order in its ideal temperature device (Heater for hot, Cooler for cold, Shelf for room).
3. If the ideal device is full, place the order on the Shelf.
4. If the Shelf is also full:
   • First, attempt to move an existing hot or cold order currently on the Shelf into its respective ideal device (Heater or Cooler), if space is available.
   • If no such move is possible, an existing order must be discarded from the Shelf to make room for the new order. The discard criterion should be thoughtfully chosen. After discarding, the new order is placed on the Shelf.

Pickup Logic

• When an order is picked up, it must be removed quickly without requiring other orders to be moved.
• If a pickup request arrives for an order not currently in the system, no action is taken.
• At the time of pickup, if the order's accumulated age has exceeded its total freshness duration (accounting for accelerated degradation if stored improperly), the order must be discarded instead of being picked up.

Action Ledger

The system must maintain a time-ordered ledger of all significant actions. Each record in the ledger must include at least:

• Timestamp
• Order ID
• Action: place, move, pickup, or discard
• Target: The storage device involved (heater, cooler, or shelf)

Constraints for the Action Ledger:

• For every order, the first recorded action must be place, and the last action must be either pickup or discard.
• Actions should be output to the console in a human-readable format as they occur.

Execution Harness (Load Test / Simulator)

A command-line interface (CLI) harness is required to simulate system load:

• It fetches a list of orders from a challenge server.
• It places orders into the system at a configurable rate (default: 500 milliseconds between orders).
• It schedules each order's pickup at a random time after placement, within a closed interval (default: 4–8 seconds).
• After all orders have been either picked up or discarded, the harness submits the complete action ledger to the server and then exits.

Non-Functional Requirements

• Concurrency: The system must be designed to safely handle concurrent placements and removals, extending beyond the scope of the provided harness.
• Efficiency: The selection of an order to discard when the Shelf is full must be more efficient than O(n) worst-case with respect to the shelf's size.
• Single Process: The entire system must operate within a single process, though it may be multi-threaded.

Explanation Requirements

Candidates must explain:

• Their proposed system architecture and approach to concurrency.
• The data structures used to enable fast order placement, efficient lookup-by-ID for removal, and efficient discard selection from the Shelf.
• The methodology for computing an order's remaining freshness, considering temperature changes.
• The chosen discard criterion and its rationale.