CDN Strategy for a Travel Platform

A boarding pass cached at a CDN edge server is a boarding pass potentially accessible to anyone who discovers the URL at that edge node. That's not a performance optimization. That's a data breach waiting to happen.

CDN strategy for a travel platform is fundamentally a security decision disguised as a performance decision. What you cache determines what's fast. What you don't cache determines what's safe. Getting the boundary right matters more than getting the cache hit rate up.

Static assets: cache everything

App bundles, images, fonts, icons, marketing content. This is the obvious CDN category. The content doesn't change between users, doesn't contain personal information, and benefits enormously from edge caching.

We configure static assets with long TTL values and content-based hashing in filenames. When we deploy a new version, the filenames change, and the old cached versions naturally expire. There's no explicit invalidation needed. The new version gets cached on first request, the old version expires after its TTL.

Our target for static asset cache hit rate is above 95%. Below that means either the CDN configuration is wrong (assets aren't being cached when they should be) or we're generating too many unique asset URLs (content hashing is too aggressive, creating many versions of the same asset).

The performance impact is significant. A traveler in Singapore loading the app gets the JavaScript bundle from a nearby edge server in under 50 milliseconds. Without CDN, that same bundle comes from our origin server, adding 200-300 milliseconds. Across all the assets needed for the initial page load, CDN shaves seconds off the experience.

Dynamic content: mostly no caching

API responses are personalized. A trip list, a booking detail, a chat message history. These are different for every user and should never be cached at the CDN.

Our edge proxy forwards dynamic requests to the origin without caching. The proxy adds value through connection optimization (keeping persistent connections to the origin, terminating TLS at the edge) but doesn't cache the response body.

There's one exception: public reference data. Airport information, airline information, and destination metadata that's the same for all users could be cached at the edge with short TTLs. We haven't implemented this yet because these queries are fast enough from the origin and the complexity of cache invalidation isn't justified by the latency improvement.

Personal documents: never cache

Passport scans, boarding passes, hotel confirmations, visa documents. These are served through time-limited signed URLs that bypass CDN entirely.

The signed URL points directly to the object storage origin, not through the CDN. The CDN never sees the request, never caches the response, and never stores the document on an edge server.

This means document access is slower than cached static assets. A boarding pass takes 200-400 milliseconds to fetch from the origin rather than 20 milliseconds from the edge. We accept this trade-off. The performance difference is imperceptible to the traveler (a few hundred milliseconds on a document they view once or twice), and the security improvement is enormous.

If we cached personal documents at the edge, we'd need to worry about: edge server compromise exposing documents, cache sharing between users (CDN misconfiguration showing user A's document to user B), cache persistence after the signed URL expires (the document lives in cache longer than the URL is valid), and compliance with data residency requirements (the document cached in a geographic region where the data shouldn't be).

None of these risks are worth the minor performance improvement.

Cache invalidation

For static assets, we don't need explicit invalidation because we use content-addressed filenames. New deploys produce new filenames. Old cached files expire naturally.

For any future cached dynamic content (like reference data), invalidation would follow a simple pattern: time-based TTL with event-based purge. The TTL ensures eventually-consistent freshness. The event-based purge handles the cases where immediate freshness matters (like an airport code change or a new airline starting operations).

We keep the invalidation strategy simple because complex invalidation logic is a source of bugs. "Did the CDN serve stale data?" is a question you don't want to ask during a production incident. Simple TTLs are predictable and debuggable.

Measuring CDN effectiveness

We track three metrics for CDN performance:

Cache hit rate for static assets. The percentage of requests served from edge cache vs. fetched from origin. Target: above 95%.

Origin offload is the reduction in origin traffic due to CDN caching. High offload means the CDN is doing its job.

User-perceived latency is the time from request to rendered content as measured by the client. This is the metric that matters for the traveler experience. A high cache hit rate means nothing if the overall latency is still poor (maybe the origin requests are still slow, or the CDN edge is far from the user).

Design your CDN strategy

For travel platforms, classify content into three tiers:

Tier 1: Cache globally. Static app assets, marketing images, fonts, public reference data. Long TTLs, content hashing, no access control needed.

Tier 2: No cache, optimize delivery. Dynamic API responses, personalized content, real-time data. Route through CDN for connection optimization but don't cache the body.

Tier 3: Bypass CDN entirely. Personal documents, sensitive user data. Serve directly from origin through signed URLs. Never touch CDN infrastructure.

The boundaries between tiers should be clear and enforced in code. A content type should never accidentally move from tier 3 to tier 1 through a configuration change. Personal documents should be served through a code path that's physically separate from the CDN-cached path.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.