MediumCake Shop · Part 3

Cake Shop 3 - Going International

DatabasesCDNGeo DistributionReplicationAPI Design

This challenge builds on Cake Shop 2 - Scaling Up. Complete it first for the best experience.

Problem Statement

Sweet Crumbs Bakery is now franchising internationally - launching in 5 countries across 3 continents. Each region has its own catalog, pricing (local currency), and regulatory constraints (GDPR in Europe, data residency in Asia).

Customers expect the same fast experience regardless of location, and franchise owners need a dashboard to manage their local catalog and view orders.

Key challenges:Latency for users on the other side of the globe from the origin server.Data that needs to stay in-region (EU orders must stay in EU).A unified authentication system across all regions.Handling currency conversion and tax rules per locale.

What You'll Learn

The bakery expands to 5 countries. Design for multi-region, currency, and localization. Build this architecture under realistic production constraints, then validate tradeoffs in the design lab simulation.

DatabasesCDNGeo DistributionReplicationAPI Design

Constraints

Regions5 countries, 3 continents
Total DAU~2 million
Latency (any region)< 200 ms
Data residencyEU data stays in EU
Currencies supported5
Availability target99.95%
ApproachClick to expand

How to Approach

Clarify requirements: Global expansion -- users in Europe and Asia experience high latency from a US-only server. Need to serve content from multiple regions.

Estimate scale: Assume 500k DAU globally. Latency from US to Europe/Asia is 150-300ms. Target: <100ms for all users.

Pick components:

  • Multi-region CDN for static assets and cacheable API responses
  • DNS with geo-routing to direct users to the nearest region
  • Keep primary DB in US, add read replicas in EU and APAC
  • API servers in each region hit the local read replica

Key tradeoffs to discuss:

  • CDN TTL: short TTL = fresher data but more origin hits; long TTL = faster but stale prices
  • Read replicas have replication lag (~50-200ms) -- acceptable for product listings, not for checkout
  • Writes still go to the primary DB in the main region -- cross-region write latency is unavoidable
  • Consider: does checkout need to be strongly consistent? Yes -- route checkout to primary region

Learn the Concept

Practice Next

Reference SolutionClick to reveal

For global expansion, add a geo-routing DNS layer to send users to the nearest region, a global CDN for static assets and cacheable API responses, and regional read replicas to reduce database read latency. Writes always go to the primary database in the main region. Checkout requests bypass the read replica and go to the primary for strong consistency.