Deployment Patterns (Blue-Green, Canary, Rolling)
Naive Deployment এর ভয়ংকর পরিণতি
একজন junior developer production-এ code deploy করতে চায়। সে যা করে: server বন্ধ করুন → নতুন code দিন → server চালু করুন। এই সময়টায় হাজারো user error দেখে। Production-এ এটা অগ্রহণযোগ্য।
Naive Deploy Flow — ভয়ংকর পরিণতি
↑ এই মাঝখানের সময়টা = DOWNTIME = users দেখে "Service Unavailable"
Amazon-এর হিসাবে ১ মিনিট downtime ≈ $৪৬০,০০০ ক্ষতি। ছোট কোম্পানির জন্যও প্রতিটা মিনিট মানে customer হারানো।
নতুন code-এ bug থাকলে পুরো server down। Rollback করতে আবার downtime। Users frustrate হয়ে চলে যায়।
একবারে সব features deploy করলেন কোনো bug কোথা থেকে এলো বোঝা কঠিন। ছোট ছোট releases best practice।
Team deploy করতে ভয় পায়। তাই weeks ধরে deploy করে না। Backlog জমে। Release আরও বড় আরও risky হয়।
📌 লক্ষ্য কী হওয়া উচিত?
Modern deployment-এর ৪টা core goal:
- ✓Zero Downtime — users কোনো interruption ছাড়াই service পাবেন
- ✓Instant Rollback — bug পেলে মুহূর্তে আগের version-এ ফিরে যানয়া
- ✓Gradual Traffic Shift — ধীরে ধীরে নতুন version-এ traffic পাঠানো
- ✓Deployment Confidence — team যেন ভয় না পেয়ে frequently deploy করতে পারে
Blue-Green Deployment — দুটো Environment রাখুন
Blue-Green deployment-এ সবসময় দুটো identical production environment থাকে — Blue (current live) এবং Green (new version)। Traffic switch করে deployment হয়। Downtime zero।
Blue-Green Deployment — ৩টি Step
# Blue Deployment (current live — v1)
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-blue
labels:
app: myapp
version: blue
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: blue
template:
metadata:
labels:
app: myapp
version: blue
spec:
containers:
- name: app
image: myapp:v1.0.0 # Current stable version
ports:
- containerPort: 8080
---
# Green Deployment (new version — v2)
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-green
labels:
app: myapp
version: green
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: green
template:
metadata:
labels:
app: myapp
version: green
spec:
containers:
- name: app
image: myapp:v2.0.0 # New version (deployed silently)
ports:
- containerPort: 8080
---
# Service — Traffic কোথায় যাবেন সেটা নিয়ন্ত্রণ করে
apiVersion: v1
kind: Service
metadata:
name: app-service
spec:
selector:
app: myapp
version: blue # ← শুধু এই একটা line change করলেনই switch!
# version: green ← Green-এ switch করতে এটা uncomment করুন
ports:
- port: 80
targetPort: 8080💡 Instant Rollback — মাত্র ১ লাইন পরিবর্তন
Green-এ কোনো problem দেখলে Service selector-এ version: blue ফিরিয়ে দিন। Blue environment এখনো চালু আছে। Traffic মুহূর্তে ফিরে যাবেন। Rollback time: seconds। কোনো re-deploy দরকার নেই।
⚠️ Blue-Green এর সমস্যাসমূহ
Double Infrastructure Cost: সবসময় দুটো full environment চালু রাখতে হয়। Cloud cost দ্বিগুণ হতে পারে।
Database Migration Complexity: v1 এবং v2 একই database use করলেন schema migration সাবধানে করতে হয়। v1 compatible migration আগে, তারপর switch, তারপর cleanup।
Canary Release — ধীরে ধীরে Traffic বাড়াও
Coal mine-এ canary পাখি ব্যবহার করা হতো বিপদ detect করতে। Software-এ Canary Release মানে নতুন version-এ প্রথমে মাত্র ৫% traffic পাঠাও। Problem না হলে আস্তে আস্তে বাড়াও।
Canary Traffic Split — Monitoring সহ
# Stable deployment (19 replicas = 95% traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-stable
spec:
replicas: 19 # 95% of total pods
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
track: stable
spec:
containers:
- name: app
image: myapp:v1.0.0
---
# Canary deployment (1 replica = 5% traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-canary
spec:
replicas: 1 # 5% of total pods
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
track: canary
spec:
containers:
- name: app
image: myapp:v2.0.0
---
# Single Service — উভয় deployment-এ route করে (label: app=myapp)
apiVersion: v1
kind: Service
metadata:
name: app-service
spec:
selector:
app: myapp # উভয় stable + canary pods match করে
ports:
- port: 80
targetPort: 8080
# Traffic split proportional to replica count:
# 19 stable + 1 canary = 20 total → 95% / 5% splitStep 1 — ৫% Traffic (Initial Canary)
১টা canary pod deploy করুন। মাত্র ৫% users নতুন version দেখবেন। Error rate, latency, business metrics monitor করুন।
Step 2 — Monitor করুন (৩০ মিনিট - ১ ঘন্টা)
Prometheus/Grafana-তে error rate দেখুন। Baseline-এর চেয়ে বেশি হলে automatic rollback। সব ঠিক থাকলে পরের step।
Step 3 — ২৫% Traffic
Canary replicas বাড়িয়ে ২৫%। আবার monitor। এখন বেশি users নতুন version দেখছে — patterns আরও clear।
Step 4 — ৫০% Traffic
Half-half split। Performance comparison সবচেয়ে accurate এখানে। A/B testing-এর মতো।
Step 5 — ১০০% Traffic (Full Rollout)
সব pods নতুন version-এ। Old pods সরিয়ে দিন। Deployment সম্পন্ন — কোনো downtime ছাড়া।
💡 Progressive Delivery with Metrics Gates
Modern tools (Argo Rollouts, Flagger) automatically পরের step-এ যায় যদি metrics threshold pass হয়। Error rate > 1%? Automatic rollback। এটাই Progressive Delivery — human intervention ছাড়াই safe deployment।
Rolling Update — একটা একটা করে Replace করুন
Rolling update-এ একবারে সব pods replace করা হয় না। একটা একটা করে (বা batch-এ) নতুন version দিয়ে replace করা হয়। সবসময় কিছু পুরনো আর কিছু নতুন pod চালু থাকে।
Rolling Update — Pod একটা একটা করে Replace
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # Extra pods: temporarily 5 pods চলতে পারে
maxUnavailable: 1 # একবারে max ১টা pod down থাকতে পারে
# maxUnavailable: 0 → zero downtime guarantee
# maxSurge: 25% → percentage ব্যবহার করা যায়
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: app
image: myapp:v2.0.0 # ← শুধু এটা পরিবর্তন করলেনই rolling update শুরু
readinessProbe: # নতুন pod ready না হলে পুরনো pod নামাবে না
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 3
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 10| Pattern | Cost | Rollback Speed | Complexity | Risk |
|---|---|---|---|---|
| Blue-Green | High (2× infra) | Instant | Medium | Low |
| Canary | Medium | Slow (gradual) | High | Very Low |
| Rolling Update | Low | Medium | Low | Medium |
Feature Flags — Code Deploy করুন, Feature আলাদা রাখুন
Feature Flag (বা Feature Toggle) হলো code-এর মধ্যে একটা on/off switch। New feature code production-এ deploy করুন, কিন্তু flag off রাখুন। যখন চাও তখন flag on করুন। Deployment আর Release আলাদা।
পুরনো উপায় (Without Flags)
Feature Flags দিয়ে
// Feature Flag Service — TypeScript implementation
interface FeatureFlag {
name: string;
enabled: boolean;
rolloutPercentage: number; // 0-100: কতজন user দেখবেন
allowedUserIds?: string[]; // Specific users (beta testers)
allowedGroups?: string[]; // User groups ('premium', 'internal')
}
class FeatureFlagService {
private flags: Map<string, FeatureFlag>;
constructor() {
// LaunchDarkly / ConfigCat / custom config থেকে load হয়
this.flags = new Map([
['new-checkout-flow', {
name: 'new-checkout-flow',
enabled: true,
rolloutPercentage: 5, // মাত্র ৫% users দেখবেন
allowedUserIds: ['user_beta_001', 'user_beta_002'],
}],
['ai-recommendations', {
name: 'ai-recommendations',
enabled: false, // সম্পূর্ণ বন্ধ
rolloutPercentage: 0,
}],
['dark-mode-v2', {
name: 'dark-mode-v2',
enabled: true,
rolloutPercentage: 100, // সবাই পাচ্ছে
}],
]);
}
// User-এর জন্য flag enabled কিনা check করুন
isEnabled(flagName: string, userId: string): boolean {
const flag = this.flags.get(flagName);
if (!flag || !flag.enabled) return false;
// Specific users override
if (flag.allowedUserIds?.includes(userId)) return true;
// Percentage-based rollout: userId hash করে consistent bucketing
const bucket = this.getUserBucket(userId);
return bucket < flag.rolloutPercentage;
}
// User ID থেকে consistent 0-100 bucket বের করুন
private getUserBucket(userId: string): number {
let hash = 0;
for (const char of userId) {
hash = (hash * 31 + char.charCodeAt(0)) % 100;
}
return hash;
}
// Runtime-এ flag update করুন (deploy ছাড়াই!)
updateFlag(flagName: string, updates: Partial<FeatureFlag>): void {
const existing = this.flags.get(flagName);
if (existing) {
this.flags.set(flagName, { ...existing, ...updates });
}
}
}
// Usage in application code:
const flags = new FeatureFlagService();
async function handleCheckout(userId: string, cart: Cart) {
if (flags.isEnabled('new-checkout-flow', userId)) {
// নতুন checkout flow (৫% users)
return await newCheckoutService.process(cart);
} else {
// পুরনো checkout flow (৯৫% users)
return await legacyCheckoutService.process(cart);
}
}Deploy — Feature Code, Flag OFF
নতুন feature code production-এ deploy করুন। Flag off থাকায় কোনো user দেখবেন না। Code live কিন্তু hidden।
Verify — Internal Team Test করুন
Team-এর specific user IDs-এ flag on করুন। Production-এ real environment-এ test। কোনো bug থাকলে এখনই ধরা পড়বে।
Flag ON — ৫% Users
Rollout percentage ৫% করুন। Real users-এর ছোট একটা group দেখবেন। Metrics দেখুন।
Monitor — Business Metrics দেখুন
Conversion rate, error rate, session duration — সব metric flag group vs control group-এ compare করুন।
Full Rollout — ১০০% Users
সব ঠিক থাকলে ১০০%-এ নিয়ে যান। পরে পুরনো code path সরিয়ে flag cleanup করুন।
📌 Feature Flags — Deployment থেকে Release আলাদা
এটাই feature flags-এর সবচেয়ে বড় insight: "Deploy" এবং "Release" এক জিনিস না। Deploy = code server-এ যানয়া। Release = users-এর কাছে feature পৌঁছানো। Feature flags এই দুটোকে সম্পূর্ণ আলাদা করে দেয়। Facebook, Google-এর মতো কোম্পানি প্রতিদিন deploy করে কিন্তু release আলাদাভাবে control করে।
কোনটা কখন Use করবো?
প্রতিটা deployment pattern-এর আলাদা tradeoff আছে। Context বুঝে সঠিক pattern বেছে নেওয়া একজন senior engineer-এর দক্ষতা।
| Pattern | Cost | Rollback Speed | Risk Level | Best For |
|---|---|---|---|---|
| Blue-Green | High (2× infra) | Instant (<1 min) | Low | Major releases, database migrations |
| Canary | Medium | Slow (gradual) | Very Low | Risky features, experimental changes |
| Rolling Update | Low | Medium (re-deploy old) | Medium | Routine updates, bug fixes |
| Feature Flags | Lowest | Instant (config) | Lowest | All use cases, A/B testing |
Real-World Decision Guide
E-commerce checkout redesign
→ Canary + Feature Flags
High business risk। ৫% দিয়ে শুরু, conversion rate monitor করুন। Flag দিয়ে instant rollback।
Critical security patch
→ Rolling Update
Fast deployment দরকার। Complex strategy-র সময় নেই। maxUnavailable: 0 দিয়ে zero downtime।
Database schema migration
→ Blue-Green
Atomic switch দরকার। Old version-কে compatible রাখুন। Problem হলে selector বদলে instant rollback।
New AI feature (beta)
→ Feature Flags
Deploy now, release later। Internal team-এ test, তারপর ধীরে ধীরে rollout। A/B test করুন।
⚠️ Feature Flag Tech Debt — পুরনো Flags পরিষ্কার করুন
Feature flags শক্তিশালী কিন্তু বিপজ্জনকও। Rollout সম্পন্ন হলে পুরনো flag এবং dead code সরাও। Netflix-এর একটা incident হয়েছিল stale flag-এর কারণে যেটা ৩ বছর ধরে ছিল। Flag lifecycle manage করুন — create, rollout, cleanup। একটা flag maximum ৩ মাসের বেশি রাখা উচিত না।
Deployment Patterns Interview Tips
System design interview-এ deployment strategy নিয়ে প্রশ্ন এখন common। সঠিক pattern propose করতে পারা senior-level thinking দেখায়।
Common Interview প্রশ্ন
- Q:"How would you deploy a new version without downtime?"
- Q:"What happens if your new deployment has a critical bug?"
- Q:"How do you deploy to a subset of users first?"
- Q:"Explain blue-green deployment and its trade-offs."
- Q:"How does Netflix/Facebook deploy thousands of times a day?"
- Q:"What is progressive delivery?"
System Design Interview-এ Deployment Strategy ব্যাখ্যা
"আমরা server restart করে deploy করবো।"
"Zero-downtime deployment-এর জন্য আমি Blue-Green deployment recommend করবো। দুটো identical environment থাকবেন। New version Green-এ deploy হবে, Blue live থাকবেন। Test pass হলে Load Balancer-এর selector Green-এ switch। Bug হলে Blue-তে instant rollback। Database migration-এর জন্য backward-compatible schema change আগে apply করবো।"
💡 সবসময় Rollback Strategy উল্লেখ করুন
Interview-এ deployment propose করলেন সাথে সাথে rollback plan বলুন: "এবং যদি কোনো issue হয় তাহলে..."
- →Blue-Green: selector পরিবর্তন — seconds-এ rollback
- →Canary: error threshold → automatic rollback to 0%
- →Rolling: kubectl rollout undo deployment/myapp
- →Feature Flags: flag off — deploy ছাড়াই instant
Real World — Netflix, Google, Facebook কীভাবে Deploy করে
Netflix
- →Spinnaker CI/CD platform নিজেরা তৈরি করেছেনে
- →Red/Black deployment (Blue-Green-এর variant)
- →Automated canary analysis (ACA) — metrics-based auto rollback
- →Chaos Engineering (Chaos Monkey) — production-এ জোর করে failure inject
- →Production Traffic Split — Gmail, Search-এ canary
- →Borg → Kubernetes (নিজেরাই তৈরি করেছেনে)
- →SRE team defines SLO → deployment blocked যদি SLO miss করে
- →Launch checklists — feature flag-এর strict governance
Facebook / Meta
- →Gatekeeper system — feature flags at massive scale
- →প্রতিদিন ১,০০০+ engineers deploy করে simultaneously
- →Tupperware (internal Kubernetes) — container orchestration
- →"2-week release train" → batch commits, canary, then full rollout
SUMMARY — আজকে যা শিখলাম
| Pattern | Key Benefit | Main Trade-off | Best For |
|---|---|---|---|
| Blue-Green | Instant rollback | 2× infrastructure cost | Zero-downtime critical releases |
| Canary | Gradual risk mitigation | Complex monitoring needed | Risky feature rollouts |
| Rolling Update | কম cost — no extra infra | Slower rollback, version mix | Resource-constrained environments |
| Feature Flags | Runtime flexibility | Code complexity বাড়ে | Dark launches & A/B testing |