Module 9 · Delivery and operations
Unit 35 of 49
Unit 35 · Module 9 · Delivery and operations
Shipping is a system too — and the rollback is the part you test least.
Unit 35 of the free 49-unit computer-science course, in delivery and operations. 6 topics to watch or read, 3 interview questions answered in full and a short self-check.
6 topics make up this unit. Take each one whichever way suits you, then answer the questions below.
Containers and VMs both isolate apps on one server, but at different layers. Containers share the host kernel (fast, dense, thinner boundary); VMs virtualize hardware (slower, isolated, any OS). In the cloud, you run containers inside VMs.
Both tools split your traffic, so 'send 10% to the new thing' sounds like one task. It is two, at two different layers. A load balancer splits VERSIONS by weight at the infrastructure layer — 90/10 at Envoy, Istio or NGINX — and it splits connections, not people, so the same user can bounce between v1 and v2 on every request. A feature flag splits BEHAVIOR inside one running service, per user, by hashing a stable id into a bucket so the same person always lands in the same group. Here is the code for both, what each one actually costs you, the rule of thumb, and how the same split shows up in an LLM serving stack.
Asked out loud, answered out loud. Read the answer, then say it in your own words.
A VM virtualises hardware and runs its own kernel — strong isolation, gigabytes, and seconds to boot. A container is a process on the host kernel, isolated with namespaces and limited with cgroups — megabytes, and milliseconds to start. The trade is exactly that shared kernel: it is what makes containers cheap and it is why a kernel escape crosses the boundary in a way it does not with a hypervisor.
Rolling: replace instances a few at a time behind the load balancer, with health checks gating each batch — cheap, and it means two versions run at once, so the schema and the API have to be compatible with both. Blue-green: bring the new version up entirely, switch traffic, keep the old one warm — instant rollback, double the capacity for a while. Canary: send a small slice of traffic to the new version and watch the error rate before continuing.
The constraint underneath all three is the database: a migration must be backwards-compatible, because during any of these both versions are talking to the same schema.
You do not roll the schema back — you make sure you never have to. Migrations are split into expand and contract: add the new column, deploy code that writes both and reads the old, then deploy code that reads the new, and only drop the old column in a later release once nothing references it. Then a rollback is just redeploying the previous image, which is a thirty-second operation instead of a restore.
The distinction worth naming: a feature flag rolls back behaviour in seconds without a deploy at all, which is why the two techniques are usually used together.
Answer alone, at 2am, with no interviewer in the room.
