Scheduling a School Canteen Ordering System
A Year 12 team is building a canteen pre-order app for a school of 900 students. The canteen can prepare 420 hot meals per lunch break. Orders open at 7:00 am and close at 10:30 am. Last term, 61% of hot-meal orders arrived in the final 40 minutes, and the canteen ran out on 9 of 50 days. The team proposes a strict first-come-first-served queue that simply rejects any order once 420 is reached. The canteen manager wants predictable workload and no student left without a meal they believe they ordered. The team also has one shared database server that becomes slow when more than 300 write requests arrive per minute.
1. Evaluate the proposed first-come-first-served rejection model against the manager's two goals. Recommend a change and justify it.
Read the worked answer
FCFS rejection meets the workload cap but fails the 'no student left without a meal' goal only partially: it is honest (the student is told at order time), yet the 61% late-arrival pattern means many students who wait until the last 40 minutes will be rejected even though the day is not genuinely full. That is a fairness and planning problem, not a capacity one.
Better: keep a hard cap of 420 confirmed hot meals, but (1) show a live count so students self-schedule, (2) allow orders from 7:00 am with a per-student one-hot-meal limit, and (3) when the cap is reached, offer a waitlist that converts if someone cancels before 10:30 am. The manager gets a known maximum; students get a clear signal and a second chance. The team should also spread load by notifying students when the count is low.
2. The server degrades above 300 writes per minute. Explain how the design should handle the 10:00-10:30 am peak, using the numbers given.
Read the worked answer
The peak problem is a rate problem, not a total-volume problem. If most of the day's ~420+ orders land in 40 minutes, average demand is over 10 orders per minute, but burstiness can push it far higher. The system should:
- Queue writes server-side with a bounded buffer and return 'pending' status rather than timing out.
- Debounce the live count (update every 10 s, not on every write) so reads do not compete with writes.
- Rate-limit per student (one submission, idempotency key) to stop double-taps creating duplicate writes.
- If the buffer exceeds capacity, degrade gracefully by accepting the order and confirming later, since the canteen cap (420) is the true constraint. The team should test with a simulated burst of 300+ writes per minute before launch.
3. A student claims they ordered but the app shows no order. Describe how the team should investigate, and what design feature would have prevented the dispute.
Read the worked answer
Investigate by checking the server log for the student's idempotency key and timestamp, whether the write reached the database, whether a timeout occurred after the write committed, and whether the client retried. The likely cause is a write that committed but whose response was lost, so the client showed failure.
Prevention: an idempotency key per order, a server-side 'confirmed orders for this student today' view, and a receipt screen showing the order id. The system should never rely on the client's local state as the source of truth. This turns an ambiguous dispute into a lookup.