Marti Soura Vamseekar

Work / MaSoVa Restaurant OS

MaSoVa Restaurant OS

A full restaurant operating system: ordering, kitchen, delivery, payments, analytics and compliance across multiple stores and tax jurisdictions.

LiveFeb 2023 – Present
masova.souravamseekar.comliveSVamseekar/masova-platform

The problem

A multi-store operator runs on four aggregator tablets, a legacy POS, a spreadsheet for stock and a separate accountant for each country's VAT. Every one of those seams is a place to lose a ticket, misprice an item, or fail an inspection.

Order lifecycle

Order 4182 · store DE-02 · takeawayRECEIVEDPREPARINGOVENBAKEDREADYDISPATCHEDIN TRANSITDELIVEREDSERVEDCOMPLETEDturns ↓← completes hereCANCELLEDany state up to readyResolved per orderVATcountry × order type × item12 marketsFiscal signature6 countries
One order, eleven states. Each transition publishes an event; tax and fiscal rules resolve from the order's own context as it advances.

An order moves through eleven states. The top row runs received, preparing, oven, baked, ready. It then wraps to the second row, read right to left: dispatched, out for delivery, delivered, served, completed. Cancelled is a terminal branch reachable from any state up to and including ready; once an order is dispatched it can no longer be cancelled. Every transition publishes an event. VAT resolves from country, order type and item category across twelve markets, and a fiscal signature is applied at completion in the six countries that require one.

How it works

  1. 01

    Every channel becomes one queue

    Orders from the storefront, the POS and the aggregators are normalised into a single stream, so the kitchen sees one list instead of four tablets.

  2. 02

    The floor gets its own surface

    Kitchen display, cashier, POS, manager and driver each get a purpose-built screen — web where the work is stationary, React Native where it moves.

  3. 03

    Tax and compliance resolve per order

    VAT depends on country, order type and item category across 12 markets; fiscal signing runs at completion where the country requires it; 14 EU allergens are enforced before an item can go live.

  4. 04

    Money is written down safely

    Financial records commit to PostgreSQL synchronously before anything downstream reads them, so payments and orders cannot drift apart.

What it covers

Customer surfaces

React 19 storefront plus a React Native app (Expo, TanStack Query, STOMP websockets) covering menu, cart, order tracking, payment, loyalty and support.

Crew surfaces

MaSoVaCrewApp ships dedicated kitchen, cashier, POS, driver and manager modules, with OTP-confirmed delivery and active-delivery tracking.

Kitchen operations

Live KDS with per-item timers and automatic status propagation as each order advances through the lifecycle.

Aggregator hub

Wolt, Deliveroo, Just Eat and Uber Eats normalised into the same order queue as first-party channels.

Compliance engine

EU VAT across 12 countries by order type and item category, fiscal signing for DE, FR, IT, BE, HU and GB, and 14 enforced EU allergens.

Intelligence

A support agent over the platform APIs handling orders, menu, loyalty, complaints and cancellation requests under JWT auth.

Engineering notes

  • Six Spring Boot 3 services on Java 21 behind Spring Cloud Gateway — 37 controllers across core (:8085), commerce (:8084), payment (:8089), logistics (:8086) and intelligence (:8087), with 207 canonical endpoints validated by an integration matrix in CI.
  • An 11-state order lifecycle in shared-models — RECEIVED through COMPLETED, with CANCELLED terminal — where every transition publishes to masova.orders.exchange.
  • Dual-write persistence: PostgreSQL synchronously for financial truth, MongoDB asynchronously for read models, Redis for auth sessions.
  • Multi-tenancy scoped to storeId with database-level isolation, plus a GDPR erasure flow that spans every service.
  • Multi-gateway payment routing — Stripe with SCA for EU stores, Razorpay for the India legacy path.

Architecture

Client surfacesCustomer webbrowse · orderCustomer appReact NativeCrew appdriver · cashierKitchen displaylive queuePoint of salein-storeAPI gatewayauth · routesServicesOrders & menucatalogue · cartsCommercepricing · VATPaymentsStripe · refundsDeliverytracking · OTPIntelligenceforecasts · agentsStatePostgreSQLfinancial · syncMongoDBread modelsRedissessionsEventsOrder exchange11 states · topic fan-outKitchen · crewlive updatesCustomerpush · reports
Five surfaces, one gateway, five services. Money commits synchronously; everything else learns by event.

Five client surfaces — customer web, customer mobile app, crew app, kitchen display and point of sale — call a single API gateway handling authentication and routing. The gateway fans out to five services: orders and menu, commerce, payments, delivery and intelligence. Orders commit to PostgreSQL synchronously for financial truth, project to MongoDB asynchronously for read models, and use Redis for sessions. Every order state transition publishes to a topic exchange that fans out to the kitchen and crew apps, customer notifications and analytics.

Trade-offs

Dual-write Postgres then Mongo

instead of a single store, or full event sourcing

Financial records need transactional guarantees; read models need shape and speed. Committing Postgres first and projecting asynchronously accepts brief read lag in exchange for money never being wrong.

Event-driven state propagation

instead of services polling each other

Kitchen, logistics and notifications all care about the same transition. Publishing once and letting consumers subscribe keeps them independent and removes synchronous coupling at rush.

Server-side VAT and fiscal resolution

instead of computing totals on the client

Tax is jurisdictional and audited. Resolving it server-side means one implementation to certify rather than one per client app.

Evidence

6

microservices

207

API endpoints

11

order states

12

VAT jurisdictions