Geography, latency, and the edge
Where your code sits relative to your users and your data is a design decision.
Physical distance costs time and nothing removes it. A request from Sydney to a server in Virginia takes roughly 200 milliseconds round trip before your code does a single thing. Multiply by the number of round trips a page needs and geography becomes the dominant term.
"The edge" means running code in many locations worldwide so that whichever one is nearest to the user handles the request. For work that needs no central data (redirects, personalisation from a cookie, serving cached content) this is a large, cheap win.
- Static files
Everywhere. This is what a CDN is for and it is nearly free. - Cached pages
Everywhere, with rules about when they expire. - Code that queries the database
Next to the database. - The database
One primary region, close to most of your users.
What to remember
- Distance sets a hard floor on response time.
- The edge only helps for work that does not need central data.
- Keep code that queries the database near the database.
Terms in this lesson
Field notes
Loaded from a deliberately slow source. The lesson above was already readable while this was still travelling. That is streaming, and it is the same trick a chat interface uses.
The digest that stopped for five weeks
A weekly email job silently stopped running after an infrastructure change. Nobody noticed, because a job that does not run produces no error. It was discovered when a customer asked whether they had been unsubscribed.
Why you alert on missing success
Everyone retried at once
A service had a brief wobble. Every client retried immediately, then again, then again. The retries were far more traffic than the original load, and the service never got a quiet moment to recover. The outage lasted forty minutes longer than the fault did.
The thundering herd
resolved in 901ms · region iad1
Hide field notes toggles a search param the loader reads. With it off, the slow promise is never created, so nothing streams.