← Lessons

quiz vs the machine

Platinum1760

System Design

Rolling Deployment

Replacing instances a few at a time to release without full duplication.

5 min read · advanced · beat Platinum to climb

Rolling deployment

A rolling deployment updates a fleet gradually. Instead of two full environments, it replaces instances in batches. A few old instances are drained and swapped for the new version, the system confirms they are healthy, then the next batch follows until the whole fleet is updated.

How it stays safe

  • A health check must pass before a new instance receives traffic
  • The batch size controls how much capacity is in flux at once
  • If a batch fails its check, the rollout pauses rather than marching on

Because old and new versions run side by side during the rollout, the application must tolerate mixed versions serving requests at the same time.

Rollback is gradual

Unlike blue green, rolling back is not a single flip. You roll forward with the old version again, batch by batch, which takes time. That is the trade. Rolling deployment avoids paying for a duplicate environment but gives up the instant rollback.

Capacity care

Draining instances reduces total capacity during the rollout, so plan batch sizes to keep enough headroom for live traffic.

Key idea

Rolling deployment swaps instances in healthy batches without a duplicate environment, but rollback is gradual and the app must tolerate mixed versions.

Check yourself

Answer to earn rating on the learn ladder.

1. How does rolling deployment differ from blue green in rollback?

2. What must the application tolerate during a rolling deployment?

3. Why plan batch size carefully?