Event-Driven Simulation And Queue State

What's being tested

This tests event-driven simulation with explicit lifecycle state: processing arrivals and departures in chronological order while enforcing capacity and FIFO waiting. You must preserve event ordering, update occupancy correctly, and aggregate revenue without double-counting customers or mishandling simultaneous events.

Patterns & templates

• Sort customers by arrival time and maintain a departure-time min-heap for occupied tables; target O(n log n) time and O(n) space.
• For each arrival, pop departures with departure <= arrival before admitting the customer; this makes capacity available at exact departure timestamps.
• Use a FIFO queue for waiting customers, storing arrival time and any immutable customer metadata required for later billing.
• Model state explicitly: occupied, waiting, revenue, and each customer’s service/departure information; avoid inferring state from partial fields.
• After every departure, admit queued customers in order while capacity remains; decide whether waiting time changes revenue or only service timing.
• Group or carefully order same-timestamp events; process departures before arrivals when a departing customer frees capacity immediately.
• Keep revenue aggregation separate from queue mutation, and use integer or decimal-safe currency arithmetic rather than binary floating point.

Common pitfalls

Pitfall: Treating the waiting queue as a priority queue by party size or departure time violates FIFO behavior; use a deque.

Pitfall: Processing arrivals before same-time departures incorrectly rejects customers when capacity should already be available.

Pitfall: Charging based on arrival time instead of actual service completion, or charging queued customers twice during promotion from the queue.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.