Clients ask why their ordering page is faster than the marketplace, and their IT people ask which datacenter it runs in. Both deserve a real answer. Here is the one behind running every storefront at 300+ locations.
Two questions come up in every restaurant project, usually weeks apart and from different people.
The owner asks why this feels faster than the marketplace app. Their IT contact — or the IT contact at the group that owns them — asks which datacenter it runs in, whether there is a DPA, and what happens if that datacenter falls over. You need an answer to both that is short, true, and does not collapse the moment someone technical pushes on it.
This is that answer, and the parts of it that are honestly limited.
Most ordering platforms are fast in the demo and slow at 19:30 on a Friday. That gap is not a throughput problem — a single mid-range server handles the order volume of a hundred restaurants without breaking a sweat. It is latency, and latency behaves differently: it does not degrade gracefully, it compounds across round trips, and it hits hardest exactly where you can least afford it — a diner on the pavement, on a phone, on a mobile network, deciding whether to keep tapping.
Take the boring version of the stack: a regional origin server, a database beside it, a CDN in front for the static assets. A diner in Portugal orders from a restaurant whose platform origin sits in Frankfurt.
Before a single byte of menu appears, the phone does a DNS lookup, a TCP handshake and a TLS negotiation. On a mobile connection to a distant origin each of those is a round trip, and TLS is often two. Call it four round trips at 60–80 ms just to open the conversation. Only then does the page request go out, and the origin has to query the menu, render, and respond.
The CDN handles the logo and the CSS. It does nothing for the part that matters, because the menu is not static — it depends on which restaurant, which opening hours, whether that dish sold out four minutes ago. The HTML is a cache miss by design, and every cache miss is a full trip back to Frankfurt.
Then stack the session on top: adding an item, applying a coupon, checking a delivery postcode, watching an order move from received to in the kitchen. Each is another trip to the same distant origin. Every individual number looks defensible in a monitoring dashboard. The sum is what the diner experiences, and the sum is where orders get abandoned.
Running at the edge is not “put a CDN in front of it.” It means the code that renders the storefront, the store it reads from, and the session it writes to are all near the diner rather than near each other in one region.
In practice: the storefront HTML renders at whichever of 300+ locations is closest, the menu read comes from a geo-replicated store rather than a single-region primary, the session and idempotency keys live in an edge cache instead of behind the origin, and menu photos are transformed to AVIF or WebP at the same location that serves them. A 2 MB photo the owner uploaded straight off a phone becomes roughly 30 KB before it reaches the diner, and it does not cross a continent to get resized.
The compounding then works in your favour. Every trip is short, so the interaction feels immediate rather than merely acceptable. Typical storefront latency lands under 50 ms to the diner — and, more usefully for you, it lands there whether the diner is in Rottweil or São Paulo, because there is no home region for them to be far from.
That is the promise you can make: not a benchmark, but the absence of a bad case. You are not claiming a number that only holds for diners near a particular city.
Be blunt about the limits, because a client who discovers them later stops believing the rest.
Writes still need coordination. Placing an order is not a read you can serve from anywhere. It has to be durable and happen exactly once, and neither property comes free from geographic proximity. What the edge contributes is that the retry is cheap: idempotency keys close to the diner mean a flaky connection that drops mid-submit resolves quickly instead of leaving someone staring at a spinner wondering whether to press again. The write is still a write.
Cold data is still cold. A restaurant with no orders for three days has no warm cache anywhere. Its first diner of the morning pays slightly more than its hundredth.
Distribution is not availability. Being in 300+ locations does not mean nothing goes wrong; it means one location going wrong is not an outage. Those are different claims, and conflating them is how you end up quoting a number you cannot stand behind. The commitment is 99.9% across the year, with maintenance scheduled outside the windows when restaurants are actually taking orders — 12:00–14:00 and 18:00–22:00 Central European Time. Quote that, not “always up.”
The interesting decision was not “use the edge.” It was refusing to assemble the platform from four vendors’ edges.
One runtime renders the storefront, runs the scheduled jobs, drives the webhook pipeline and transforms the images. One data store holds the menu, the orders and the accounts. One auth system covers the diner’s magic link and the manager’s dashboard login. Nothing in the ordering path is a network hop to a different company’s product.
That sounds like an aesthetic preference until you price it. A stack glued together from a hosting provider, a managed database in one region, an image CDN, a queue and a websocket service has a cost floor set by five vendors’ minimums — and every hop is somewhere latency and failure get added. Collapsing them is what makes $20 a month a coherent price rather than a loss leader, and it is why your eleventh restaurant costs you almost nothing more than your tenth.
The practical effect is the absence of questions.
There is no region to pick during onboarding, so nobody guesses whether a client’s future expansion lands in the wrong hemisphere. The procurement form’s “which datacenter” line has an honest one-line answer: it runs in all of them, and here is the DPA. There is no separate CDN account, image service or websocket vendor for a client’s IT department to audit, which shortens the security review from a list of five suppliers to one. And when the owner asks why their site is faster than the marketplace’s, the answer fits in a sentence you can say out loud without hedging.
None of that is glamorous. It is mostly the removal of decisions that should never have been your client’s problem — and, more to the point, never yours to defend.
Be among the first studios on Margord. No credit card required.