API / Microservices Design Patterns Interview Questions
What is the Canary Deployment pattern and how does it differ from Blue-Green deployment?
The Canary Deployment pattern releases a new version of a service to a small percentage of production traffic first, monitors it closely for errors, latency regressions, and business metric anomalies, then gradually increases its traffic share until it serves 100% — at which point the old version is decommissioned. The name comes from the "canary in a coal mine" practice of using a small probe to detect danger before full exposure.
Blue-Green Deployment maintains two complete, identical production environments — Blue (current live) and Green (new version). Traffic is switched from Blue to Green all at once (or very rapidly). If Green has a problem, rollback is instant: switch traffic back to Blue.
| Aspect | Canary | Blue-Green |
|---|---|---|
| Traffic shift | Gradual (1% → 10% → 50% → 100%) | All-at-once switch |
| User exposure to new version | Small initial subset of users | All users at switch time |
| Infrastructure cost | Only canary instances needed alongside full production | Two full production environments run simultaneously |
| Rollback speed | Seconds (redirect traffic back) | Seconds (flip the switch) |
| Best for | Validating new features on real traffic before full exposure | Pre-validated releases where instant cutover and instant rollback are required |
# Istio VirtualService â 5% canary traffic split apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: { name: order-service } spec: hosts: [order-service] http: - route: - destination: { host: order-service, subset: v1 } weight: 95 - destination: { host: order-service, subset: v2-canary } weight: 5
Canary deployments require automated monitoring with clear rollback triggers: if canary error rate or P99 latency exceeds a threshold within the observation window, traffic is automatically redirected back to the stable version.
More Related questions...
