Edge Caching, Explained Without the Buzzwords
What actually happens when a user hits your site — and how edge caching turns 300ms into 30ms.
When a user in Tokyo types your URL, their request doesn’t travel to your server in Virginia. It travels to the nearest edge node — in this case, our Tokyo PoP in Otemachi. That node is maybe 38 milliseconds away.
Without edge caching, Tokyo forwards the request to Virginia. Virginia builds the page, sends it back. Round trip: 280ms on a good day, 400ms on a bad one. The user stares at a white screen.
With edge caching, Tokyo already has the page. It was fetched once, stored locally, and served to every subsequent visitor from the same node. The response time drops to 38ms — the distance to the edge, not the origin.
What gets cached?
Static assets are obvious: images, CSS, JavaScript, fonts. These never change between deploys, so they’re cached aggressively with long TTLs.
Dynamic content is where it gets interesting. API responses, HTML pages, even GraphQL queries can be cached at the edge if you’re smart about cache keys. A product page that updates every 10 minutes? Cache it for 9 minutes. A search results page? Cache it per query string for 5 minutes.
Cache invalidation
The hardest problem in caching is knowing when to throw things away. Nodus supports three strategies:
- TTL-based — set an expiry, let the edge refetch automatically
- Tag-based — associate content with tags, purge by tag when you deploy
- Instant purge — clear everything, useful for emergencies
Most teams start with TTL, add tags when they hit scale, and use instant purge once in a blue moon.
The bottom line
Edge caching isn’t magic. It’s just moving data closer to the people asking for it. The magic is having 320+ locations to move it to.
