Rolling deployment
Replace running instances a few at a time so the service never goes down, with old and new versions live together during the swap.
See it
What it is
Instead of switching everything at once, you replace instances batch by batch, waiting for each new one to report healthy before moving on, until the whole fleet is new. Whether a batch adds the replacement first or removes an old instance first is a setting, not a law. In Kubernetes, maxSurge is how many extra instances you may run above the target and maxUnavailable is how many you may be missing, so maxSurge 1 with maxUnavailable 0 brings up a healthy new instance before retiring an old one, while maxUnavailable 1 with maxSurge 0 does it the other way and runs briefly short-handed. This is the default strategy in Kubernetes Deployments and in most container platforms.
Reach for it when you want zero downtime without paying for a second full environment. It is the cheap, boring, correct choice for stateless web services. Note it is not a canary: a rolling update is not measuring anything about the new version, it is just replacing machines on a schedule.
Gotcha: during the roll, old and new code serve traffic at the same time. Your API responses, queue messages, and database schema all have to work in both directions, and a user can hit v2 then v1 on the next click. Rollback is also slow, because undoing means rolling the whole fleet back batch by batch.
Ask AI for it
Configure a rolling deployment for this service. Replace instances in small batches (for example maxSurge 1, maxUnavailable 0), wait for each new instance to pass its readiness/health check before retiring an old one, and stop the rollout automatically if a batch fails to become healthy. Drain connections gracefully on the instances being retired. Assume old and new versions run simultaneously, so keep API responses and database changes backward compatible for at least one release.