# Keep the stable release compatible with canary writes

A small rollout still changes shared data. Separate incompatible schema and behaviour changes so the stable application remains a usable recovery path.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## List what the candidate can write

Include database fields, event formats, cached values and external effects. The canary may share all of them with the stable release even when it receives little traffic.

For an illustrative status change, the candidate might write awaiting-review while the stable code recognises only pending and complete. Returning traffic to stable can then fail on records created during the trial.

Resolve that compatibility before enabling exposure. A traffic percentage does not reduce the meaning of an unsupported stored value.

## Expand readers before new writes

Where appropriate, deploy support for the new representation while keeping existing behaviour. Verify that both old and new data can be read under the supported release sequence.

Then introduce the candidate's new writes behind a controlled exposure rule. Keep the database migration and feature activation as separate observable steps.

If compatibility cannot be maintained, define a different recovery strategy and state its consequences. Do not present ordinary traffic rollback as available when it is not.

## Exercise the reverse traffic path

Write representative data through the candidate, abort the rollout and continue the workflow through stable. Include background consumers and cached representations.

Test unknown outcomes and duplicate requests across versions. Both releases need a coherent interpretation of operation identity where they share the same business effect.

Inspect the stored result independently so a friendly error page does not conceal a damaged record.

## Remove compatibility later

After promotion and the required recovery window, identify consumers that still need the old representation. Scheduled jobs and retained events may extend that period.

Remove old fields and fallback paths in a separate reviewed change when their dependencies are gone. This makes the irreversible boundary visible.

Keep the rollout record clear about which builds remain safe to deploy. A list of available container images is not enough to establish that each one can operate on today's data.

## Sources

- [Argo Rollouts: canary deployments](https://argo-rollouts.readthedocs.io/en/stable/features/canary/)