Serving Travelers on Every Continent

A traveler in Bangkok opens the app to search for flights. The server is in North America. That's roughly 12,000 miles of network distance. Light travels fast, but physics still applies. A round trip over the internet adds 200-400 milliseconds of latency before any processing even begins. If the flight search takes 2 seconds of processing time, the traveler in Bangkok waits 2.4-2.8 seconds. Same search from New York takes 2.1 seconds.

That 500 millisecond difference might seem small, but it compounds. Every API call, every page load, every interaction adds the latency tax. Over a 20-minute planning session, the Bangkok traveler experiences a noticeably sluggish app compared to the New York traveler. We can't move the laws of physics, but we can be smart about what runs where.

CDN for static assets

The easiest win is serving static assets from the edge. Our app bundles (JavaScript, CSS), images, fonts, and other static content don't change between requests. They can be cached on edge servers worldwide and served from the nearest one.

When the Bangkok traveler loads the app, the JavaScript bundle comes from an edge server in Singapore (a few milliseconds away), not from our origin server in North America (400 milliseconds away). The app loads fast. The user interface appears quickly. The perceived performance is good before any API call happens.

We configure aggressive caching for static assets: long TTLs, immutable headers for versioned assets, and automatic cache invalidation on deployment. Static asset cache hit rates should exceed 95%. Below that, something is wrong with the caching configuration.

Edge computing for the API proxy

Our web client routes API requests through an edge proxy. This proxy runs at the edge, close to the traveler, and handles several latency-sensitive operations before forwarding to the origin.

The proxy handles cross-site request forgery token management, request validation, and authentication token refresh at the edge. These operations don't need access to the database or the AI agent. Doing them at the edge saves a round trip to the origin for common operations.

For AI chat requests (which do need the origin for inference), the proxy adds minimal overhead. The request goes edge-to-origin, but the proxy handles the server streaming stream efficiently, buffering and forwarding tokens to the client without adding per-token latency.

The edge proxy also provides resilience. If the origin is briefly unreachable, the proxy can serve cached static assets and return appropriate error messages rather than hanging indefinitely.

What stays at the origin

Not everything can run at the edge. The AI agent, the database, the payment processing, and the booking confirmation all run at the origin. These operations require access to centralized state (conversation context, booking records, payment intents) that can't be replicated to the edge without significant complexity.

We accept the origin latency for these operations because they're inherently heavy. A flight search takes 1-3 seconds of processing time regardless of where it runs. The 200-400 milliseconds of network latency to the origin is a fraction of the total time. Optimizing the processing time matters more than optimizing the network path for these requests.

The booking confirmation target is under 5 seconds globally. For a traveler in Bangkok, that means the processing needs to complete in about 4.5 seconds, leaving room for the network round trip. For a New York traveler, the processing budget is slightly more generous. We monitor these per-region to ensure global service quality.

Measuring global performance

We run synthetic monitoring from multiple geographic locations. Automated requests from test points in North America, Europe, Asia, South America, and Oceania measure real-world latency for key operations: page load, API response time, and flight search duration.

This monitoring catches regional degradation that aggregate metrics miss. If our average API response time is 200 milliseconds but the P95 for Asian users is 800 milliseconds, the average hides the problem. Per-region monitoring surfaces it.

We also collect real user metrics from the mobile and web clients. These are more accurate than synthetic monitoring because they reflect actual device performance, network conditions, and user behavior. A synthetic test from a server in Singapore on a fast connection tells a different story than a real user in rural Thailand on a cellular connection.

Seasonal considerations

Travel traffic has geographic seasonality. Summer vacation planning peaks in North America and Europe during March-April. Golden Week travel in Japan peaks in late April. Chinese New Year booking peaks in January. Holiday season booking peaks globally in October-November.

These seasonal patterns shift the geographic distribution of our traffic. During North American summer planning, most traffic comes from US and European time zones. During Golden Week, Asian traffic spikes. We monitor these patterns and ensure our infrastructure serves each region well during their peak periods.

We don't dynamically move infrastructure between regions (that would be over-engineering for our scale). But we do ensure that no region's performance degrades during another region's peak. The Bangkok traveler shouldn't get slower service because Americans are booking summer vacations.

Planning your global strategy

If you're building a platform that serves global users:

Serve static assets from the edge. This is the lowest-effort, highest-impact optimization.

Accept origin latency for complex operations. AI inference and database transactions need centralized state. Don't try to replicate them globally unless your scale demands it.

Measure from the user's perspective, not the server's perspective. Server-side latency metrics miss the network round trip that's the biggest variable for distant users.

Monitor per-region, not just globally. Aggregate metrics hide regional problems. A regional degradation can go unnoticed for weeks if you're only watching the average.

Design for your traffic patterns. If 80% of your users are in one region, optimize for that region first. Expand globally when user demand justifies the infrastructure investment.

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.