Design a Multi-Region User Profile Service
An international e-commerce company wants to ensure high availability for its User Profile & Address Book service. The service serves user profile details, saved addresses, and payment preferences during checkout. While reads account for 98% of the traffic, write availability must be maintained even when an entire cloud region goes offline.
Design a multi-region deployment architecture using a primary (active) region and secondary (passive) region that can handle seamless read routing, data replication, and rapid failover in the event of a regional outage.
- Retrieve user profile data and saved shipping addresses by User ID.
- Create, update, and delete user profiles and addresses.
- Automatically route read/write traffic to the secondary region when the primary region becomes unavailable.
- Replicate profile updates continuously from the primary region to the secondary region.
- High availability target of 99.99% across the multi-region setup.
- Read latency under 50ms (p95); write latency under 200ms (p95).
- Recovery Time Objective (RTO) < 1 minute for region failover.
- Recovery Point Objective (RPO) < 5 minutes of data loss during catastrophic primary outage.
10 million total registered users, 1 million DAU. Peak read throughput is 2,000 QPS; peak write throughput is 50 QPS. Average profile record size is 2 KB (total database footprint ~20 GB).
- High-level architecture diagram showing Global Traffic Management/DNS, primary region services, and secondary region services.
- Data replication architecture between primary and secondary databases.
- Health monitoring and automated regional failover workflow.
- Data model schema for user profile and address entities.
Candidate specifies a clear traffic routing strategy (Global Load Balancer or DNS health-check routing like AWS Route53/Cloudflare) that automatically redirects incoming user traffic from Primary to Secondary region upon health check failures within 60 seconds.
Candidate designs cross-region asynchronous database replication (e.g., PostgreSQL physical streaming replication or Aurora Global Database), addressing replication lag and ensuring RPO < 5 minutes.
Candidate provides a relational or document data model for user profile and address records, alongside an in-region cache (e.g., Redis) strategy to keep read latency under 50ms.
Candidate demonstrates how user reads avoid stale cached data immediately after updates, and details how write requests are handled safely during the failover transition period.
Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.
Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.
Follow-up: If a user updates their shipping address in the secondary region immediately after a failover, how do you handle data reconciliation and prevent write conflicts when the primary region comes back online?
Total dataset fits within standard database limits (~20 GB). Read traffic is heavy (98%), writes are light (2%). Maximum acceptable Recovery Point Objective (RPO) is 5 minutes, and Recovery Time Objective (RTO) is under 1 minute for automatic failover.
- Views
- 7