Chopora
Online Restaurant Ordering
An online restaurant platform covering the complete ordering path: browsing the menu, building a cart, placing an order and paying for it. It is a smaller project than some of the others here, but it is a complete commercial workflow — and commercial workflows are where small modelling mistakes become expensive very quickly.
Technology
The problem
The restaurant ordering problem is mostly a data-modelling problem wearing a user-interface costume. A cart has to survive being abandoned, prices have to be read from the database rather than trusted from the browser, an order has to be an immutable record of what was agreed, and a payment has to attach to a specific order without any ambiguity about which transaction settled which basket.
Approach
- 01
Made the database the authority on price. Items and totals are read server-side at checkout, so a modified request cannot change what is owed — the same principle that governs every paid workflow I build.
- 02
Modelled cart, order and payment as separate records. An order captures what was agreed at that moment and does not change afterwards; the payment references it. That separation is what makes the payment traceable to a specific basket.
- 03
Kept payment as a workflow with verifiable states rather than a redirect that hopes for the best, so an order's fulfilment status always agrees with what actually happened.
- 04
Used Bootstrap to keep the interface responsive and dependable — a restaurant menu has to be legible and tappable on a phone, and that outcome matters more than the styling approach.
- 05
Added order management so incoming orders are visible and actionable, not just recorded in a table nobody reads.
Architecture
- 01
Menu
Menu items and categories are served from the database and rendered as a browsable, responsive listing.
- 02
Cart
The cart holds selected items and quantities, with totals recalculated from stored prices on the server rather than trusted from the client.
- 03
Order placement
Placing an order creates a durable record capturing the agreed items and total at that moment.
- 04
Payment
Paystack handles the transaction, and its outcome is recorded against the specific order rather than a global flag.
- 05
Order management
Orders are surfaced for the restaurant to review and act on, closing the loop from customer to kitchen.
Order and payment are separate records. That is what makes it possible to tell which transaction settled which basket.
Key features
Challenges
Not trusting the client with prices
A cart in the browser is a suggestion. Every total is recalculated from database prices when the order is placed, so the amount charged is the amount the restaurant actually expects.
Attributing a payment to the right order
Global payment flags fall apart the moment two people order at once. The payment has to reference a specific order so transaction history is unambiguous and orders can be reconciled.
What I learned
Paid workflows are mostly about attribution. Once an order, a transaction and an entitlement are separate records that reference each other, most of the confusing payment bugs simply stop being expressible.