Cloud & Infra Design
This is where operations stops being about one host and becomes designing a system that survives failure, absorbs unpredictable load, and does not bankrupt you. The cloud hands you primitives — regions, availability zones, managed services, autoscaling, storage tiers — but it does not decide for you; every default is a trade-off you own. The single idea running through everything here is assume the machine dies: instances are cattle, not pets, so availability comes from spreading across independent failure domains, not from buying one bigger, more reliable box.
The first layer builds the mental model of the cloud itself: the IaaS/PaaS/SaaS ladder and who is responsible for what, why a region is not an availability zone, why multi-AZ is the baseline unit of high availability while multi-region is expensive disaster recovery, and how elasticity, load balancing, storage tiers and pricing models turn into a monthly bill you can control. The second layer puts those primitives to work in full system designs — highly available multi-tier apps, zero-downtime deploys, observability and secrets at scale, disaster recovery, autoscaling for spiky traffic and layered caching — each one naming the concrete trade-off it decides.
Topic map
- Cloud architecture — IaaS/PaaS/SaaS and shared responsibility, regions versus availability zones, multi-AZ as the HA baseline versus multi-region DR, elasticity versus scalability, managed versus self-hosted, L4/L7 load balancing, storage tiers and spot/reserved/on-demand pricing.
- Infra system design — HA multi-tier architecture, zero-downtime deploys and schema migrations, observability and logging at scale, secrets architecture, disaster recovery (RPO versus RTO), autoscaling for spikes, capacity planning and layered caching.
Common traps
| Mistake | Consequence |
|---|---|
| Running many instances in one AZ and calling it HA | One zone outage takes the whole service down |
| Treating multi-region as the cheap default | Paying for cross-region replication and egress you did not need; the answer was multi-AZ |
| Confusing elasticity with scalability | Provisioning for peak 24/7 and never scaling back down |
| Confusing RPO with RTO | Buying fast failover when you needed frequent backups, or the reverse |
| Shipping a destructive schema change with the code | Old instances break mid-rollout; an outage instead of a zero-downtime deploy |
| Caching with no invalidation or stampede guard | Stale data forever, or a thundering herd when a hot key expires |
Interview relevance
Cloud and infra design is where senior interviews live: the interviewer hands you a vague scenario and watches whether you reach for independent failure domains, name your single points of failure, and quantify the trade-off you are making. A strong answer sounds like "I put stateless instances across three AZs behind an L7 load balancer with health checks, run the database multi-AZ with failover, and accept the cross-AZ latency" — every clause is a decision with a cost.
Typical checks:
- Region versus AZ, and why multi-AZ (not instance count) delivers high availability.
- Shared responsibility across IaaS/PaaS/SaaS.
- RPO versus RTO and the mechanisms each drives.
- Expand/contract for a zero-downtime schema migration.
- Where caching gets hard: invalidation, TTLs and stampedes.
Common wrong answer: "high availability just means running more servers." More servers in one zone is redundancy against a single instance dying, not against a zone, a region, or a bad deploy — availability is about where and how independently those servers fail, not how many there are.