CDN vs origin delivery for a SaaS app with EU and APAC users
Global performance ↔ Infrastructure simplicity
Context
Deliver a web app and marketing site to users in the EU and APAC from one origin.
Our origin is in Frankfurt; a third of our users are in APAC, where the app feels sluggish (TTFB around 600 ms from Singapore).
Option A: put a CDN in front of everything: static assets and the marketing site cached at the edge, the app's HTML and API passed through.
Option B: stay origin-only and optimise the app instead.
What worries me with A is caching something personalised by accident.
Constraints
- Origin
- Frankfurt
- Users
- 55% EU, 35% APAC, 10% US
- Pages
- Static marketing + personalised app
Serve through a CDNvsServe directly from the origin
Community verdict
9 engineers · 5 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
Simplicity →
Trade-offs
Dimensions
- Global latency
- 5Serve through a CDN scores 5 of 52Serve directly from the origin scores 2 of 5
- Simplicity
- 3Serve through a CDN scores 3 of 55Serve directly from the origin scores 5 of 5
- Cache correctness
Community discussion
5 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentIf APAC is a third of revenue, consider an APAC region for the API as well. A CDN hides asset latency, not a 300 ms round trip on every API call.
Bonus: DDoS absorption and a WAF at the edge. Your origin stops being reachable by the whole internet.
Only if the origin rejects traffic that does not come from the CDN. Lock that down or attackers just bypass it.
Static assets on a CDN is a no-brainer: hashed filenames, immutable cache headers, done. Even for uncached API calls, the CDN terminates TLS near the user and reuses warm connections to the origin, which cuts real latency.
For personalised responses, send
Cache-Control: private, no-storeand make the CDN respect origin headers.Origin-controlled caching is the key. No path-based "cache everything" rules.