System Design Foundations

Cloud Computing Models

“Move to the cloud” is not one decision. Running a VM you patch yourself, pushing a container to a platform that scales for you, and buying a finished CRM are three different responsibility contracts—and three different outage stories.

This note maps , , and to what you still own under , how vs failures feel, and how regions and zones bound .

Responsibility ladder

You run OS → app. Provider runs metal and hypervisor.

You ship app/config. Platform runs runtime and often scale.

You configure and govern data. Vendor runs the product.

Identity, data classification, and misuse remain yours.

What actually happens

A sells density: many customers share facilities and often logical control planes. Providers isolate tenants with accounts, hypervisors, encryption keys, and quotas. You still design for shared fate—region events, IAM mistakes, and noisy neighbors on less isolated tiers.

Most architectures mix models: object storage and managed databases as , app compute on containers or VMs, and human workflows on SaaS. Interviews reward naming the mix and the residual duties, not chanting “cloud-native.”

Geography matters. A is a failure and latency domain; give you independent power and networking inside that region. Crossing boundaries costs latency and often .

How to choose IaaS vs PaaS vs SaaS

1. Do you need OS-level control? Custom kernels, exotic networking, or regulated host agents push toward (or bare metal). If you only need “run this container,” prefer PaaS or managed container platforms.

2. Is the capability a commodity product? Email, SSO, ticket desks, and many analytics warehouses are better as unless differentiation or data residency forces ownership.

3. Where is your differentiation? Put engineering time on the product core; buy undifferentiated heavy lifting as managed services—then budget for lock-in and export drills.

Simple rule of thumb

Buy SaaS for commodity workflows, PaaS when delivery speed beats OS knobs, IaaS when isolation or control is the product requirement. Always draw the shared-responsibility line for identity and data.

Stack layers by service model

Diagram text: the exact Mermaid definition below preserves the nodes, labels, and connections. Enable JavaScript to view the rendered diagram.

Read the diagram definition

flowchart TB
    subgraph FAC["Facility"]
      PWR[Power / cooling / physical security]
    end
    subgraph HV["Virtualization"]
      HYP[Hypervisor / host OS]
      NET[Underlay network / fabric]
    end
    subgraph GUEST["Guest / platform"]
      OS[Guest OS / patch]
      RT[Runtime / middleware]
    end
    subgraph APP["Application"]
      CODE[Your code / config]
      DATA[Data / identity / access]
    end
    FAC --> HV --> GUEST --> APP
    CUT1[IaaS cut: you own guest OS upward]
    CUT2[PaaS cut: you own app + data]
    CUT3[SaaS cut: you own data governance]
    HV -.-> CUT1
    RT -.-> CUT2
    CODE -.-> CUT3

Layer	IaaS	PaaS	SaaS
Facility / network fabric	Provider	Provider	Provider
Hypervisor / host	Provider	Provider	Provider
Guest OS / patching	You	Provider	Provider
Runtime / scaling plumbing	You	Mostly provider	Provider
Application code	You	You	Provider
Data / identity / misuse	You	You	Shared (you own config)

Shared responsibility in practice

On IaaS, an unpatched guest OS is your incident. On managed Postgres, OS patching is theirs—but an open security group, weak DB user, or missing encryption-at-rest toggle is still yours. On SaaS, a phishing-resistant SSO policy and least-privilege admin roles are the difference between a vendor outage and a company-wide data leak.

Encryption is a frequent confusion. Providers offer KMS and disk encryption; you still decide key policy, who can decrypt, and whether application-level encryption is required. Logging is similar: the platform emits trails; you must retain, alert, and investigate.

Diagram text: the exact Mermaid definition below preserves the nodes, labels, and connections. Enable JavaScript to view the rendered diagram.

Read the diagram definition

sequenceDiagram
    participant Attacker
    participant IAM as Your IAM / IdP
    participant CP as Cloud control plane
    participant DP as Data plane (buckets/VMs)
    participant Prov as Provider security

    Attacker->>IAM: Steal over-privileged token
    IAM->>CP: Create keys / open policies
    CP->>DP: Exfiltrate objects or snapshots
    Note over Prov: Provider did not "get hacked"
    Note over IAM,DP: Shared responsibility: identity & config were yours
    Prov-->>CP: Still protects hypervisor & facility

Usually still your job

Identity providers, MFA, role design, secrets handling
Network exposure (public endpoints, security groups)
Data classification, retention, residency, deletion
Application authZ bugs and tenant isolation
Backup restore drills and exit/export plans

Usually the provider’s job

Physical security, power, cooling
Hypervisor isolation between tenants
Underlay DDoS and fabric availability (within SLAs)
Managed service OS/runtime patching where advertised
Control-plane API authenticity and regional operations

Control plane vs data plane

Interviewers listen for this split. Your API can keep serving while you cannot launch new instances. Autoscaling, healing, and deploys depend on the ; user requests depend on the .

plaintext

Control-plane heavy moments:
  - blue/green cutover creating thousands of tasks
  - incident: replace unhealthy nodes
  - Terraform apply opening security groups
  - certificate renewal that recreates listeners

Data-plane heavy moments:
  - peak shopping traffic on existing fleet
  - object GET/PUT at steady state
  - DB queries against provisioned capacity

Design habit:
  Keep warm capacity and runbooks that do not require
  fresh provisioning when the control plane is degraded.

Regions, zones, and blast radius

Diagram text: the exact Mermaid definition below preserves the nodes, labels, and connections. Enable JavaScript to view the rendered diagram.

Read the diagram definition

flowchart LR
    subgraph R1["Region A"]
      AZ1[AZ 1]
      AZ2[AZ 2]
      AZ3[AZ 3]
    end
    subgraph R2["Region B"]
      AZ4[AZ 1]
      AZ5[AZ 2]
    end
    User((Users)) --> GLB[Global DNS / anycast]
    GLB --> AZ1
    GLB --> AZ2
    GLB --> AZ4
    AZ1 -.async replicate.-> AZ4
    AZ1 --- AZ2
    AZ2 --- AZ3

Account structure is also blast radius. One shared cloud account with god-mode roles means a bad deploy script or compromised CI can touch everything. Separate prod/non-prod accounts, workload accounts, and break-glass roles shrink accidents.

Managed services inherit the provider’s topology rules. A “multi-AZ database” still has failover semantics and RPO/RTO you must read. Assuming automatic multi-region failover without designing it is a common trap.

Cost and coupling signals

Cloud bills encode architecture. Chatty cross-AZ traffic, internet , and idle over-provisioned IaaS dominate many invoices. PaaS and serverless shift spend to request/time units—great until a runaway loop or fan-out job.

Coupling shows up as proprietary APIs, IAM models, and data gravity. Export drills and abstraction at the seams (open protocols, portable schemas) are engineering, not politics. Over-abstraction that fights the platform is the opposite failure mode.

plaintext

Rough decision cues:

  High differentiation compute + special networking
    → IaaS / containers with more control

  Standard web/API workload, team wants speed
    → PaaS or managed container platform

  Commodity workflow (HR, email, tickets)
    → SaaS; invest in SSO and DLP

  Always ask:
    - Who patches what?
    - What is RPO/RTO of the managed dependency?
    - Can we restore from backup we control?
    - What happens if control plane is down for 2 hours?

Trade-offs

Choice	Gain	Cost
IaaS-heavy stack	Max control, portable mental model	Patching, capacity, slower delivery
PaaS / managed runtime	Speed, less OS toil	Opaque limits, harder deep debug
SaaS for core workflow	Zero ops for that product	Vendor roadmap, data gravity, exit cost
Many managed services	Leverage provider SLAs	Integration sprawl, lock-in, bill surprise
Multi-AZ only	Solid regional HA, moderate cost	Shared regional control-plane risk
Active multi-region	Lower correlated outage risk	Sync complexity, egress, consistency
Single shared account	Simple start	Huge blast radius on IAM mistakes

Worked example: “we’re cloud-native” outage

A team runs apps on a managed container platform (PaaS-like), uses managed Postgres, and stores uploads in object storage. During a regional control-plane degradation they cannot scale or redeploy. Existing tasks keep serving until a dependency restart needs new capacity—then errors cascade.

plaintext

What they said: "Provider owns availability."
What shared responsibility actually said:
  - app retries / timeouts / bulkheads: customer
  - warm capacity / multi-AZ placement: customer design
  - IAM least privilege: customer
  - DB failover RPO understanding: customer
  - provider facility & hypervisor: provider

Fix narrative for interviews:
  1. Keep baseline capacity above peak without relying on create APIs
  2. Multi-AZ for stateful stores; practice failover
  3. Circuit-break and shed when dependencies slow
  4. Separate deploy account permissions from runtime roles
  5. Document control-plane vs data-plane runbooks

Choosing and explaining cloud computing models

A complete explanation connects the mechanism to a requirement. Describe what improves when you introduce it, which new failure cases become possible, and how you would know that the trade-off is worthwhile.

Explain the core idea

Name IaaS, PaaS, and SaaS as different cuts of who operates which layer—not as buzzwords.

Draw shared responsibility for the exact services in the design: identity and data almost always remain yours.

Separate control-plane risk from data-plane risk, and place workloads across AZs (and regions when justified).

When it belongs

Choosing managed databases, serverless, or self-managed VMs.

Discussing security ownership, compliance, or “who patches what.”

Explaining multi-AZ vs multi-region and blast radius.

How it fails

Assuming the provider owns application identity mistakes.

Designs that require control-plane creates during incidents.

Single-AZ stateful systems marketed as highly available.

Unbounded egress or chatty cross-region topologies.

Trade-offs to weigh

Control and portability versus operational leverage.

Delivery speed on PaaS versus debuggability and knobs.

Multi-region resilience versus cost and consistency complexity.

Common misunderstandings

Treating “the cloud” as one homogeneous model.

Confusing encryption available with encryption correctly configured.

Equating SaaS with zero residual security duty.

Ignoring account and IAM structure as blast-radius tools.

Wrap-up

Cloud models are contracts about operations and risk. Great designs mix IaaS, PaaS, SaaS, and managed services deliberately, with a clear shared-responsibility story and topology that matches the blast radius you can afford.

Exercises

Draw the cut line. For a video-upload service using object storage, managed queue, and self-managed encode VMs, list who patches and who owns IAM for each component.
Control vs data. Write a two-hour runbook that assumes create-instance APIs fail but existing VMs still route traffic.
Region choice. Argue when multi-AZ is enough versus when active multi-region is worth egress and conflict resolution for a payments ledger vs a marketing CMS.

Key takeaway

IaaS, PaaS, and SaaS shift the operations boundary; they do not remove your duty for identity, data, and resilient design. Know the cut line, the control plane, and the failure domain before you claim the architecture is “highly available.”