CravingsPH: correctness under concurrent restaurant work

Why is restaurant work a concurrency problem?

A table session can connect guests, several staff members, multiple orders, payment progress, kitchen work, and a shared floor view. Those actors do not wait politely for one another, so a superficially simple status change can race with settlement, cancellation, or fulfillment work.

CravingsPH joins public restaurant and menu discovery to the operational path after a guest arrives: opening a table session, creating linked orders, moving work through preparation and service, settling one or several orders, and keeping the floor view current.

What did I own?

I designed and built the product across public discovery, restaurant administration, table sessions, orders, transactional persistence, realtime floor behavior, and kiosk access. That end-to-end boundary made product states and correctness rules part of the same design rather than separate frontend and backend concerns.

Why use three coordinated state regions?

Lifecycle, payment, and fulfillment answer different questions. A session can remain open while one order is served and another is preparing; payment can be partial without rewriting fulfillment history. Modeling those concerns as named regions preserves their independence while cross-region guards reject combinations the restaurant should never see.

• Lifecycle records whether the session or order remains actionable
• Payment records unpaid, partial, settled, or reversed progress
• Fulfillment records queued, preparing, ready, and served work
• Guards validate the combined state before a command commits

How do simultaneous commands remain safe?

Every mutation carries a command identifier, validates current state, and locks affected rows in deterministic order inside a transaction. Repeated commands can be recognized, while competing actions either produce one consistent result or a benign conflict that tells the caller the intended transition was already resolved elsewhere.

Multi-order settlement validates the complete set before changing any member. This avoids a half-settled table when one linked order fails a rule and makes the user-facing result explainable: the operation commits together, retries safely, or returns a conflict without silently losing work.

What role does realtime play?

Realtime events make committed restaurant changes visible quickly, but they are not the authority for correctness. Floor and order screens reconcile their caches against persisted state after relevant events, so a missed, delayed, or repeated message does not become the business record.

How is a shared kiosk bounded?

A kiosk is paired through a short-lived flow and receives restaurant-scoped device trust. The device can perform the narrow guest-facing work it needs without storing or inheriting an unrestricted staff account session.

What does the reviewed product demonstrate?

The early-partner implementation demonstrates transaction and workflow design across the restaurant journey: explicit state, deterministic mutation boundaries, recoverable realtime projections, and scoped kiosk authority.

It does not yet establish broad adoption, production transaction scale, active payment settlement, universal POS replacement, or commercial success. Those outcomes require separate operational evidence and remain outside this case study.