3.8 Seconds in Europe: Caching, Replicas, or Multi-Region?
An e-commerce company runs its storefront in us-east-1: an Application Load Balancer, an autoscaling EC2 fleet, and an Amazon Aurora MySQL writer with two readers in the same region. 62% of traffic comes from Europe and Southeast Asia, where users see p95 page loads of 3.8 seconds versus 1.1 seconds for US users. Product pages are identical for all anonymous visitors for up to 10 minutes and account for 70% of requests. Checkout and cart APIs are dynamic and write to the Aurora writer. The team wants a fix that ships in one quarter, keeps a single writable database, and finance has asked for the monthly delta between the options presented.
1. Break the 3.8 seconds down. What do you fix first, and what evidence justifies that order?
Read the worked answer
Do not start with architecture - start with a measurement that separates network time from server time.
- Split p95 into DNS + TLS + time-to-first-byte + download, ideally real-user monitoring segmented by country, cross-checked with synthetic tests from Frankfurt and Singapore. If TTFB is low and the rest is round-trip time, it is physics (distance); if TTFB is high, it is the origin.
- Cache first. 70% of requests are anonymous product pages, explicitly invocable for up to 10 minutes. A CDN turns those into edge hits: this addresses distance and origin load simultaneously, needs no schema change, and is reversible. It is the highest ratio of latency removed to risk taken.
- Then reads. The remaining dynamic reads can be served from Aurora readers placed closer to those users, reducing the number of ocean crossings per page.
- Then writes. Checkout still has to reach the single writer in us-east-1 - roughly two ocean round trips per transaction. Accept that, and shrink it by reducing sequential calls rather than by moving the writer, which the constraint forbids anyway.
Shipping anything before the measurement exists means you cannot prove the delta finance asked for.
2. Choose among a CDN, a global accelerator, and an Aurora global database with cross-region replicas. Justify against the one-quarter, single-writer constraints.
Read the worked answer
- CDN - yes, primary. Global edge presence for cacheable HTTP content, origin offload, and a clean TTL story for the 10-minute freshness window. Constraint check: no database change, shippable in weeks.
- Aurora global database / cross-region read replicas - yes, secondary. Gives low-latency local reads for dynamic content and a disaster-recovery promotion path, while keeping exactly one writable primary, which matches the stated constraint. Note the replication lag and the fact that reads may be slightly stale - route only tolerance-bearing queries there.
- Global accelerator - only if justified. It helps for non-HTTP protocols or when static anycast IPs and deterministic routing are required, and it does not cache. With a cacheable, HTTP-only storefront, most of the win is already captured above; adding it is a cost with overlap.
Rejected: full active-active multi-region with multi-writer. It violates the single-writer constraint, requires conflict resolution for cart state, and cannot be delivered by a team in one quarter without a dedicated platform effort. Say this explicitly so it stops being re-proposed.
Sequence: CDN, measure, then replicas if dynamic reads still dominate.
3. What does this cost, and where could the fix make things worse?
Read the worked answer
Give finance a delta with the offsetting savings named, not just the new line items.
New costs: CDN request and egress charges (usually cheaper per GB than direct internet egress, so partly self-funding), cross-region data transfer for replication to the new readers, and the readers themselves. Offsetting savings: with ~70% of requests served at the edge, origin fleet size and origin egress drop; if autoscaling was sized for peak cache-miss traffic, headroom shrinks. Net delta is often smaller than it first appears - present both columns.
Where it makes things worse:
- Staleness becomes a business bug. A 10-minute TTL is fine for browsing and wrong for a flash sale or a price correction. You need a purge mechanism and an owner for it; otherwise the first incident after launch is a customer seeing a stale price.
- The cache does nothing for logged-in users. Cart and checkout remain slow for the 62% of traffic that matters most at conversion time. Set expectations now.
- Replica reads can lag. Serving a just-updated order status from a lagging replica creates support tickets that look like data loss.
- Cache hit ratio is not guaranteed. Measure it; a low hit ratio means you paid for a CDN and kept the origin load.