02.04 · Concept
The Problem, Stated
State the deployment problem precisely: moving a live system between states without dropping work already in flight.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
Deployment is a controlled state change of a live system, not just copying new code onto machines. The hard part is preserving accepted work while code, configuration, schema, processes, and routing overlap. Safe deployment depends on draining old work, maintaining compatibility, and treating rollback as another risky transition.
What this lesson answers
- what is the real deployment problem
- how to deploy without dropping in flight work
- why can rollback fail after database migration
Notes
Deployment Problem — The deployment problem exists because a live service must move from version to version while preserving in-flight requests, jobs, connections, and data invariants; without it, users see dropped work, partial writes, broken sessions, or incompatible reads.
Key Concepts: - A deployment is a state transition where includes code version, config, database schema, runtime processes, and traffic routing. - “Work in flight” includes HTTP requests taking , background jobs running for , WebSocket sessions lasting hours,…
References
Common questions
- What counts as work in flight during deployment?
- Work in flight is anything the system has accepted but not safely finished. That includes HTTP handlers still running, queued jobs, open connections, uncommitted transactions, and messages already claimed by workers. If termination, routing changes, or schema changes invalidate that work, deployment has caused a correctness failure, not just an availability blip.
- Why is running old and new versions at the same time risky?
- During a rolling change, both versions may read the same rows, consume the same queue formats, call the same APIs, and serve the same users. If either version assumes a schema, message shape, or response contract the other does not honour, the overlap window can produce broken reads, failed deserialisation, or corrupted workflow state.
- What makes a deployment safe for live traffic?
- A safe deployment starts the new version, stops routing fresh work to the old version, and lets the old version finish what it already accepted before it exits. It also requires retry or compensation for work that cannot be preserved directly, plus data and API compatibility across the period where both versions exist.
Short definition: what is Problem, Stated?