A collaborative product with long-lived client connections needs zero-downtime releases. How do rolling, blue-green and canary differ here?

Why stateful changes the analysis

For a stateless service, all three strategies are straightforward. With long-lived connections, every strategy must answer a question stateless services do not face: what happens to the connections held by the instance being replaced?

The strategies

Rolling. Replace instances gradually. For a connection-holding tier, each replacement disconnects that instance's sessions — so a rolling deploy is a series of reconnection events, and without protocol support it is a self-inflicted version of the platform's worst failure mode.

Blue-green. Two environments, traffic switched. Clean for stateless services and awkward here: switching disconnects every session at once, which is worse than a rolling deploy's staggered version. It also doubles capacity cost during the release.

Canary. A small proportion of traffic to the new version, with health gates before proceeding. The right default, because it bounds the blast radius of a bad release — but for a connection-holding tier "traffic" means new connections, so the canary population grows slowly and the signal takes longer to accumulate.

What actually makes it work

Draining as a protocol feature. Before an instance is removed, it tells clients to reconnect on a server-scheduled stagger. Combined with session resumption — a sequence number and a bounded replay buffer, so reconnecting means "send me what I missed" — a rolling deploy becomes nearly invisible.

This is the decisive capability. Without it, no release strategy is good; with it, rolling plus canary works well.

Long, jittered connection lifetimes so connections are recycled continuously rather than only at deployment, which also solves the standing problem that load imbalance persists once connections are established.

Backward-compatible protocol changes, using expand-and-contract, because old and new clients coexist for as long as clients take to reconnect — which may be hours.

The database dimension

Schema changes must be backward compatible across the release, since both versions run simultaneously. That means expand-and-contract migrations regardless of release strategy — the deployment strategy does not change the schema constraint.