Production SaaS Infrastructure

The final capstone. Design the infrastructure for a platform serving five million users on two continents, justify every component you add — and defend everything you chose not to build. Then the failures arrive.

Design the production infrastructure for a SaaS platform serving 5 million users across Europe and the United States. You will be asked to justify every component — and to defend everything you chose not to build.

What the platform runs

An HTTP APIPostgreSQL as the system of recordRedis for caching and sessionsObject storage for user filesA worker fleetA job queueA CDN for static and media delivery

Requirements

Every one of these has to be answerable by pointing at something in your design.

  • High availability — a zone failure must not be user-visible.
  • Low latency for users on both continents.
  • Secure tenant data, with isolation you can explain to an auditor.
  • Automated deployment with a rollback that takes minutes, not hours.
  • Backups with a stated RPO and a tested RTO.
  • Observability sufficient to diagnose an incident without guessing.
  • Moderate cost sensitivity — the bill is scrutinized, but reliability wins ties.

Decision areas

In order. 0 of 12 covered.

  1. Must cover
    • • Which region owns writes
    • • How users are routed
    • • What a full region loss costs in data and downtime
    Multi-Region DeploymentActive-Passive FailoverActive-ActiveRegions and Availability Zones
  2. Must cover
    • • Public entry points and why each one is public
    • • Private placement of data and workers
    • • Egress path, and whether it is zone-redundant
    Virtual Private CloudPublic and Private SubnetsNAT GatewaySecurity Groups: The Stateful FirewallPrivate Connectivity
  3. Must cover
    • • The compute model and why
    • • Whether orchestration is justified at this size
    • • How long-running jobs survive a deploy
    Choosing a Compute ModelKubernetes Is Not Always NeededGraceful Shutdown: The 502 Spike Nobody Investigates
  4. Must cover
    • • User files and how they are uploaded
    • • The CDN origin
    • • Lifecycle for old data
    Object StorageDirect Uploads and Signed AuthorizationStorage Lifecycle: Hot, Warm, Archive, DeleteCDN as Infrastructure
  5. Must cover
    • • Primary placement and standby
    • • Read scaling and the staleness it introduces
    • • Tenant isolation
    Managed DatabasesMulti-Zone DeploymentStateful Workloads: Databases Are Not Stateless APIs
  6. Must cover
    • • Workload identities rather than shared credentials
    • • Least privilege per component
    • • Blast radius of a compromised worker
    The IAM ModelHuman vs Workload IdentityLeast Privilege in InfrastructureRoles vs Static Keys
  7. Must cover
    • • Secret storage and runtime retrieval
    • • Rotation without a rebuild
    • • Audit of secret access
    Secrets in InfrastructureKey Management and Encryption at RestConfiguration Belongs Outside the Image
  8. Must cover
    • • Build once and promote
    • • Rollout strategy and its compatibility requirement
    • • Rollback time
    Build Once, Promote the Same BytesFour Ways to Replace Running CodeCanary: Let 5% of Traffic Find the BugInfrastructure as Code
  9. Must cover
    • • The scaling signal for the API and for the workers
    • • Startup time and the headroom it forces
    • • Behaviour under a spike
    AutoscalingAutoscaling SignalsStartup Time & Cold Start
  10. Must cover
    • • Symptom-level alerts
    • • Infrastructure signals worth watching
    • • Deploy markers and audit trails
    Infrastructure ObservabilityInfrastructure LogsAudit Trails
  11. Must cover
    • • Backup placement in a separate failure domain
    • • Stated RPO and a measured RTO
    • • A restore drill
    RPO & RTOBackup StrategyRestore TestingDisaster Recovery
  12. Must cover
    • • Egress and cross-region transfer
    • • Idle capacity versus headroom
    • • Per-service attribution
    Cost EngineeringEgress: Moving Data Costs Money, Not Just Storing ItIdle Capacity: Headroom or Waste?Right-Sizing Without Causing an OutageCost per Service and the Attribution Problem

Now break it

Pick a failure and read the two outcomes side by side. The distance between them is the value of every decision above.

No failure injected yet

Pick one above. Each injection has exactly two endings, and your design decides which one you get.