iTranslated by AI
Is the design ready for gradual releases?
Is it designed for phased releases?
Background and Overview
Releasing all at once in a production environment increases the blast radius if an incident occurs.
By incorporating mechanisms for phased rollouts such as canary releases, feature flags, and A/B testing from the design stage, you can introduce changes into production with confidence.
Examples
- Enable features for internal users first by toggling a Feature Flag.
- Use revision concurrency or incremental traffic shifting to route 50% of traffic to a new version (e.g., Cloud Run revision features, AWS App Runner traffic routing, Azure Container Apps revision-based deployment).
- Display a banner on the screen on the release date to clearly communicate the intent of a phased rollout.
Common Failures
- The code was written without considering canary releases, leading to inconsistencies caused by version differences.
- Poor control over feature flags resulted in changes being deployed to unintended users.
- Log analysis became difficult after switching versions, leading to delays in issue detection.
FAQ
Q. Won't Feature Flags become technical debt?
A. It is not an issue if you establish operational rules to remove them promptly after release. Forgetting to delete flags is the primary cause of debt.
Q. At what granularity should canary releases be performed?
A. By feature, user attribute, request volume, etc. While the ability to switch at the smallest possible unit provides high flexibility, it is a case-by-case decision.
Related Perspectives
- Is the impact scope of changes organized, and is component reuse considered?
- If system downtime is required, is it planned to be minimized?
📘 This article is part of the SaaS Design Review Perspective Checklist (2025 Edition).
Design perspective category: 🚀 Release/Rollback
Level: DeepDive (Implementation/Operation level)
Recommended readers: Design leaders / SREs / Infrastructure designers / Reviewers
🧭 Click here to read other perspectives.
Discussion