- Platforms integrated
- Four
- Order path
- Real time
- Backend
- Go + NATS
A restaurant POS is only as valuable as the systems it connects to. We built the core Go services behind the Salido platform, then the integration surface that keeps reservations, menus and delivery marketplaces in step with the floor.
01 The problem
A point-of-sale system sits at the centre of a restaurant, but almost nothing it needs is under its own control. Reservations live in one vendor. Menu and pricing data lives in another. Delivery orders arrive from marketplaces that each model a basket differently and expect an answer in seconds. Every one of those is a different protocol, a different data model and a different failure mode — and an order that arrives late, twice, or not at all is a real table with real people sitting at it.
02 The core services
We built and maintained the backend behind the platform: Go services handling real-time order flow and payments across distributed systems, with NATS carrying messages between them and PostgreSQL behind. The brief throughout was reliability and low-latency APIs in a high-throughput production environment, with service boundaries clean enough that one vendor integration failing could not take the floor down with it.
03 The integration surface
Four third-party platforms, each with its own shape:
- SevenRooms — reservation, guest and dining data synchronised directly into the POS, so the floor sees the same guest record the host stand does.
- OpenTable — reservation and guest management workflows wired into front-of-house operations.
- Woflow — menu, pricing and catalog data ingested and normalised, so what the delivery platforms show matches what the kitchen will actually make.
- Stream — catalog synchronisation and real-time order creation with Uber Eats, DoorDash and other online ordering platforms, with low-latency propagation of menu changes and inbound orders.
04 Why it held
Integration work fails in predictable ways: someone treats a third party as if it were a local function call, and the first timeout takes down the thing that pays the bills. Each integration here was built as its own service boundary with its own failure behaviour, so a vendor outage degrades one capability rather than the restaurant.