Design a Scalable Global Web Application — System Design Interview Practice

Interview prompt

Design a globally deployed web application with low-latency delivery, elastic compute, multi-region data decisions, safe migrations, and resilient authentication.

• Define global routing, static and dynamic caching, session/authentication state, regional ownership, and the consistency model for writes.
• Explain active-active versus active-passive regions, failover detection, data replication, conflict handling, and recovery point/objectives.
• Use progressive delivery and expand/contract database migrations without taking regions offline.
• Explain autoscaling, cache invalidation, abuse protection, observability, cost controls, and degraded read behavior.

Requirements and scale assumptions

• Serve authenticated and anonymous pages through global routing and CDN caching, with origin APIs for personalized reads and writes.
• Support user signup/login, profile updates, content CRUD, cache purge, deployment health, and region-aware request routing.
• Provide backups, migration rollback, regional failover, idempotent mutations, audit logs, and privacy deletion semantics.
• Meet p95 global page load under 2 seconds and API p95 under 200ms for users near a healthy region.
• Scale elastically across regions and traffic spikes without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• 10M daily users across 5 regions with 20x traffic bursts
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 20x burst; 5 regions — Capacity assumption that drives partitioning and backpressure.
• Latency target: p95 page load < 2s; API < 200ms — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — Regional databases and deployment artifacts are authoritative; CDN and caches are disposable projections.
• Async boundary: At-least-once workers — Keep App Engine for application hosting, Cloud SQL for relational database, Cloud Storage for static files off the synchronous path.

Key entities

• AccessSessionsessionId, principalId, roles, credentialVersion, expiresAt

  Short-lived authenticated session for scalable global web application with revocation and rotation metadata.

• GlobalResourceStaterecordId, ownerId, status, version, createdAt, updatedAt

  Authoritative globally owned application state protected by tenant and role policy.

• AuditEventeventId, principalId, action, resourceId, policyVersion, occurredAt

  Tamper-evident access, policy, and deployment evidence for scalable global web application.

• MigrationCheckpointmigrationId, partition, sourceVersion, targetVersion, checkpoint, status

  Replayable scalable global web application migration or recovery progress.

Data flow

1. 1. Protect ingress and authenticateThe scalable global web application edge validates transport, identity, roles, quotas, and network-zone policy before routing the request.
2. 2. Authorize and commit private stateThe application enforces resource policy and conditionally commits scalable global web application state before returning a durable version.
3. 3. Publish audit and domain eventsAn outbox emits scalable global web application changes, access evidence, and migration work only after the private store commit.
4. 4. Run migrations and side effects asynchronouslyPartitioned workers process scalable global web application exports, notifications, migrations, backups, and repairs with checkpoints and bounded retries.
5. 5. Fail over and restore safelyHealth checks, backups, restore tests, replay, and audit evidence recover scalable global web application after a tier or zone failure.

Deep dives and trade-offs

• Network isolation and identityPlace scalable global web application data stores in private zones and expose only narrow service-to-service paths. Use short-lived credentials, role checks, secret or certificate rotation, and deny-by-default policies. Log policy decisions without putting tokens or sensitive payloads into traces.
• Safe migrations and concurrencyVersion scalable global web application records and use expand-migrate-contract for schema changes. Checkpoint large migrations by partition and make retries idempotent. Reject stale writes rather than allowing a slower tier to overwrite newer state.
• Backups, restore, and degraded readsTest scalable global web application restore procedures, not just backup creation, with measured recovery objectives. Keep caches and projections rebuildable from private authoritative state. Expose degraded or read-only mode when a write dependency or zone is unavailable.
• Global active-active versus regional ownershipKeep scalable global web application writes regionally owned or partitioned and replicate derived reads globally. Cross-region active-active writes increase conflict, identity, and recovery complexity.
• Synchronous versus asynchronous side effectsCommit the protected business state synchronously and queue audit exports, notifications, and migrations. Making every side effect synchronous widens the failure domain and leaks provider latency into user requests.
• Cache availability versus data freshnessCache only safe reads with TTL and invalidation metadata, and fall back to the private store for critical decisions. A stale cache must never bypass authorization or become the only copy of data.