Backend architecture

One Fastify Backend, Four Clients: Kiosk, Web, Rider, Admin

Four different front ends, one API, one database. The trick is not the framework. It is deciding early that nothing gets its own copy of the menu.

Author

Published

Updated

Length

8 min · 1,000 words

Key takeaways

  • A shared API removes the sync problem instead of solving it: there is only one copy of menu, stock, and coupons.
  • WebSockets push order status to the console, the customer tracking page, and the rider at once.
  • Prisma gives typed access to one PostgreSQL schema across every service that needs it.
  • Docker on GCP keeps deployment repeatable and always-on.
  • Adding a fifth client later is an API consumer, not a data migration.

In the SVSFood project, four apps needed to agree on the same facts: what is on the menu, what is in stock, which coupon is valid, and where an order is right now. The cheapest way to make them agree is to give them nothing to disagree about.

Rule one: no private copies

The kiosk does not cache a menu it believes is authoritative. It reads from the API and keeps a local copy only as a fallback. The website and the console read the same endpoints. Change a price once and the next request everywhere sees it.

Rule two: push, do not poll

An order moves through states: placed, accepted, picked up, en route, delivered. Each transition is written once, then broadcast over WebSockets. The admin feed, the customer's tracking page, and the rider app all update from the same event.

Rule three: one typed schema

Prisma over PostgreSQL gives the team one schema file as the contract. TypeScript across the kiosk, console, website, and API means a renamed field breaks the build, not a Saturday dinner rush.

Frequently asked questions

Why use one backend for kiosk, website, rider app, and admin console?

Because the business objects (menu, inventory, coupons, orders) are the same. One backend means one place to enforce rules, and one real-time channel to keep every screen consistent.

What stack did the SVSFood backend use?

Fastify on Node.js, PostgreSQL with Prisma ORM, WebSockets for live order status, and Docker deployed on Google Cloud Platform.
FastifyPostgreSQLPrismaWebSocketsArchitecture

Related technical writing

Product engineering

Firing a Kiosk Vendor: Rebuilding SVSFood's Ordering Stack From Scratch

Three outlets, one vendor, a subscription per terminal and downtime nobody controlled. Here is why I replaced the whole thing with code the client owns, and what it cost to do it properly.

Data & backend

Supabase and PostgreSQL: How I Ship Auth, Realtime, and Relational Data

Supabase is not a shortcut around backend engineering. It is managed PostgreSQL, auth, and realtime so I can spend engineering time on orders, payments, and integrations.

Infrastructure

Docker in Production: Repeatable Deploys for Client APIs

Docker is not a buzzword on my stack list. It is the contract that lets the same Fastify API run on my laptop, in CI, and on Google Cloud Run without “works on my machine.”

Links

© LINKS °

Let's build together. Waiting to connect.

Book A Call

https://vishu.app/book

©2025Vishu Pratap · Software Developer