Is your booking API a server or a client?
A server to a million phones, a client of payments and the database. The roles belong to each connection, not the machine.
The server owns the data and rules: one deploy fixes a bug. What does that cost?
The cost
It’s a bottleneck and a single point of failure, and every client pays network latency to reach it.
603 ms
before any server work, Pune to US East
TCP, TLS 1.3, then the request, plus DNS. That’s three 201 ms round trips. So reuse connections and finish handshakes at a nearby CDN edge.
Where do sessions live?
Bad: In the server’s memory
Sticky sessions: a crash or deploy logs out everyone on that box.
Good: Shared store or signed token
Any server takes any request; add servers to scale.
Who is allowed to talk to the database?
Two-tier: every install holds database credentials and its own connection. Three-tier: only the app servers reach it, and the rules live in one place.
A seat frees up. How does the server tell your phone?
The asymmetry
It can’t open a connection: most phones sit behind NAT. The app keeps one open: long polling, SSE, WebSockets or mobile push.
The app sends price: 1. What does the server charge?
The real price. Anyone can call your API with a script, so recompute prices and permissions from your own data.
Remember
Clients ask; servers answer and own the truth. Run many stateless servers, count round trips, and never trust the client.