system-design

Part 9 — Deployment & Infrastructure

How the systems you’ve designed actually get built, shipped, run, and paid for. The gap between “it works on the whiteboard” and “it runs reliably in production.”

Time for this part: Week 10 on the Standard track. Deployment and operations come up in senior design interviews as “how would you deploy/scale/run this?” — and cost is the single most under-used seniority signal in the whole loop.

The unifying idea: operability is a design property. Containers, orchestration, CI/CD, deployment strategies, and IaC all exist to make deploying and running software safe, repeatable, and reversible — and to make “how is this configured?” a question with an answer.

---

Chapters

Packaging and running

#	Chapter	Time	The problem it solves
1	VMs, Containers, and Docker	18 min	Shipping the environment with the code
2	Kubernetes for System Designers	20 min	Orchestrating hundreds of containers — and when not to
7	Cloud Provider Primitives	16 min	The same building blocks under different names

Shipping safely

#	Chapter	Time	The problem it solves
3	CI/CD Pipelines	16 min	Frequent, small deploys are safer than rare, large ones
4	Deployment Strategies	16 min	Zero downtime and limited blast radius
5	Feature Flags & Progressive Delivery	16 min	Decoupling deploy from release
6	Infrastructure as Code	14 min	Version-controlled, reproducible infrastructure

Running at scale

#	Chapter	Time	The problem it solves
8	Multi-Region & Disaster Recovery	22 min	Surviving a region failure; serving the globe
9	Capacity Planning & Autoscaling	16 min	How much you need, and why autoscaling isn’t magic
10	Cost Optimization	16 min	The bill is a design constraint

---

The things to remember

1. Containers are isolated processes (namespaces + cgroups), not lightweight VMs — and they ship the environment with the code, killing “works on my machine.”
2. Kubernetes is declarative desired state with a reconciliation loop — that’s what makes it self-healing. And most teams adopt it before they need it.
3. Frequent small deploys are safer, not riskier — build the artifact once, promote it, and make rollback fast.
4. Canary limits blast radius; blue-green gives instant rollback; feature flags decouple deploy from release. Every zero-downtime strategy runs old and new versions together, so they must be compatible.
5. Multi-AZ is cheap resilience; multi-region is a big, deliberate step. Active-active’s hard part is writes — shard by region to avoid conflicts. And test your DR, or it doesn’t work.
6. Autoscaling lags and can’t handle spikes or cascades; the database doesn’t scale with the app tier. Keep headroom.
7. Cost is a design concern. Egress is the #1 surprise. Bringing up cost unprompted is a strong seniority signal.

---

Before moving on

You should be able to answer these without notes:

• Explain the difference between a VM and a container, and why containers are just processes.
• Explain Kubernetes’ declarative/reconciliation model and when not to use it.
• Explain why frequent small deploys are safer, and why to build the artifact once.
• Compare canary, blue-green, and rolling on blast radius vs rollback speed.
• Explain how feature flags decouple deploy from release, and flag debt.
• Explain RTO/RPO and the active-active write-conflict problem.
• Explain why autoscaling can’t handle sudden spikes, and the app-tier/database mismatch.
• Name the top cost drivers, especially egress, and the main pricing-model levers.

---

Next: Part 10 — Performance & Scaling Playbooks — the concrete techniques for finding and fixing bottlenecks, and the story of scaling from one user to a billion.

This site is open source. Improve this page.