# Fintek API'si için Canary mi, Blue-Green deployment mı?

> Rutin sürümlerde Canary'yi varsayılan yapın, instant rollback istediğiniz büyük cutover'lara Blue-Green'i saklayın; ikisi de geriye uyumlu şema şart koşar.

- Soruldu: 2026-06-10
- Yanıtlandı: 2026-06-12
- Soran: Bora
- Etiketler: ci-cd, dayaniklilik
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/canary-mi-blue-green-mi-fintek-api-icin-deploy-stratejisi/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Binlerce kullanıcının anlık işlem yaptığı kritik bir fintek API'ımız var ve yeni sürüm çıkarken riski sıfırlamak istiyoruz. İki seçenek var: tüm trafiği bir anda yeni ortama almak (Blue-Green) ya da trafiğin %1'ini yeni sürüme verip logları izlemek (Canary).

Altyapı maliyeti, veritabanı şema değişikliği (backward compatibility) ve rollback hızını düşünerek hangi senaryoda hangisini seçerim?


Kısa cevap: Yüksek riskli bir fintek API'da rutin sürümler için **Canary**'yi varsayılan yapın; anında çevirebileceğiniz/geri alabileceğiniz büyük cutover'lar için **Blue-Green**'i elinizde tutun.

Asıl mesele şu: ikisi de aynı problemi farklı maliyetle çözüyor — yeni sürümü canlı trafikle, ama kontrollü şekilde sınamak.

1. **Canary: en küçük blast radius, en güvenli varsayılan.** %1 trafik → hata oranı, latency ve iş metriklerini izleyin → kademeli ramp. Gerçek dünya hatalarını çok küçük bir kullanıcı kitlesiyle yakalarsınız. Bir fintekte rutin sürümün doğal seçimi budur.
2. **Blue-Green: en hızlı rollback, en pahalı altyapı.** Tam bir ikinci ortam ayağa kaldırır, trafiğin tamamını anında oraya çevirirsiniz. Rollback neredeyse anlık (geri çevirin) ve temiz bir pre-prod test ortamı verir; ama altyapıyı ikiye katlar ve %100'ü aynı anda riske atar.
3. **Belirleyici nokta veritabanı.** Her iki stratejide de eski ve yeni sürüm bir süre **aynı anda** çalışır. Bu yüzden şema değişiklikleri geriye uyumlu (expand/contract) olmak zorunda — migration backward-compatible değilse ne Canary ne Blue-Green sizi kurtarır; eski kod yeni şemada patlar.
4. **Rollback hızı vs. maliyet dengesi.** Blue-Green ≈ anlık geri dönüş ama yüksek maliyet; Canary hızlı (ağırlığı geri alın) ve ucuz. Para hareketi olan bir API'da bu denge, "ne sıklıkta ve ne kadar riskli deploy ediyorsunuz" sorusuyla çözülür.

**Sonuç:** Ben olsam günlük sürümler için Canary'yi standart yapardım — en düşük risk, en küçük etki alanı. Büyük, riskli cutover'lar (major sürüm, altyapı taşıması) için Blue-Green'in instant rollback'ini saklardım. Ama strateji ne olursa olsun değişmeyen kural: her migration'ı geriye uyumlu yazın. Şema disiplinini kurmadan hiçbir deploy stratejisi sizi güvende tutmaz.

## İlgili Yazılar

- [Hata oranı artınca otomatik rollback yapan (self-healing) deploy altyapısını nasıl tasarlarım?](https://www.muhammetsafak.com.tr/sor-bakalim/hata-artisinda-otomatik-rollback-ve-kendi-kendini-iyilestiren-deploy/) — Sor Bakalım
- [CI/CD'de OIDC ve IAM Role ile şifresiz (secretless) AWS erişimini nasıl kurarım?](https://www.muhammetsafak.com.tr/sor-bakalim/ci-cd-de-secret-yonetimi-ve-oidc-ile-sifresiz-erisim/) — Sor Bakalım
- [CI/CD'de veritabanı göçlerini (migrations) güvenli nasıl çalıştırırım?](https://www.muhammetsafak.com.tr/sor-bakalim/ci-cd-de-veritabani-goclerini-guvenli-calistirmak/) — Sor Bakalım