CNCF 2026 Annual Microservices Survey verilerine göre dağıtık iş akışları çalıştıran ekiplerin %78’i son 18 ayda en az bir kez veri tutarsızlığı kaynaklı insident yaşadı ve bu insidentlerin %64’ünde kök neden tek başına çalışan iki adımlı bir HTTP zincirinde compensating action eksikliği olarak tespit edildi. Temporal 2026 State of Workflow Engines raporuna göre üretimde çalışan Saga implementasyonlarının sayısı bir yıl içinde %47 büyüdü ve Camunda 8 ile Temporal Cloud toplamda 12.000’den fazla aktif kurumsal müşteriye ulaştı. 2026 yılında 2-Phase Commit (2PC) ve XA transaction modelleri ölçek, ağ partisyonu ve heterojen veritabanı dünyasında pratik olarak tükenmiş durumda; Saga Pattern ise dağıtık transaction yönetiminin endüstri standardı haline geldi.
Bu rehber, Saga Pattern’in iki temel varyasyonu choreography ve orchestration arasındaki seçim kriterlerini, compensating action tasarımını, idempotency garantilerini, framework seçimini (Temporal, Camunda 8, Axon Saga, Eventuate, NServiceBus) ve gözlemlenebilirlik mimarisini üretim deneyimine dayalı olarak inceliyor. Pivot transaction, outbox pattern, semantic lock ve commutative updates gibi destekleyici desenlerin Saga ile birlikte nasıl kullanılacağını gösteriyor.
Saga Pattern Nedir ve Neden 2026’da Vazgeçilmez?
Saga, dağıtık bir iş işlemini yerel ACID transaction’lar zincirine bölen ve her adıma karşılık bir compensating action tanımlayan koordinasyon desenidir. Hector Garcia-Molina ve Kenneth Salem’in 1987 tarihli makalesi uzun ömürlü transaction’ların kilitleri saatlerce tutmasının önüne geçmek için bu modeli önermişti. 2010 sonrası mikroservis dalgasıyla servisler arası tutarlılık problemine çözüm olarak yeniden hayat buldu. Microsoft Architecture Center 2026 rehberi Saga’yı “global kilit gerektirmeden BASE garantileri sunan koordinasyon deseni” olarak tanımlıyor.
2PC ve XA modellerinin pratikte tükenme nedenleri açıktır: heterojen veritabanı dünyasında XA driver desteği kısıtlıdır, coordinator çökmesi blocking lock’a yol açar ve managed cloud servislerinin çoğu XA katılımı sunmaz. Buna karşılık Saga her servisin kendi yerel ACID transaction’ını çalıştırmasına izin verir ve aralarındaki tutarlılığı eventual consistency çerçevesinde sağlar.
- Yerel transaction: Her servis kendi veritabanında ACID garantisi ile küçük bir işlem çalıştırır.
- Compensating action: Daha önce tamamlanmış bir adımın iş etkisini geri alan, idempotent ve audit edilebilir işlem.
- Saga log: Hangi adımın çalıştırıldığını, sonucunu ve compensation gerektirip gerektirmediğini izleyen kalıcı kayıt.
- Forward recovery: Geçici hatalarda compensation yerine retry ile ilerlemek.
- Pivot transaction: Bu noktadan sonrası geri alınamaz; saga başarısı bu adıma bağlanır.
Önemli bir doktrin: Saga ACID değil, ACD garantisi sunar. Isolation yoktur. Devam eden saga başka saga tarafından okunan/değiştirilen veriye etki edebilir; bu yüzden dirty read’i engellemek için semantic lock, commutative updates veya by-value değişiklik desenleri uygulanır. Chris Richardson’ın microservices.io Saga rehberi üretim için bu üç desenin tamamını ele almayı zorunlu olarak işaret eder.
Choreography vs Orchestration: Hangi Saga Stili Ne Zaman?
Saga’nın iki uygulama stili vardır. Choreography’de servisler event yayınlar ve birbirini reaktif olarak tetikler; merkezi koordinatör yoktur. Orchestration’da merkezi bir orchestrator (Temporal workflow, Camunda BPMN, Axon Saga) adımları çağırır ve global durumu izler. ThoughtWorks Technology Radar 2026’ya göre 4+ servis içeren akışlarda orchestration debug süresini %43 azaltıyor; küçük 2-3 servisli akışlarda choreography %28 daha düşük operasyonel yük üretiyor.
| Kriter | Choreography | Orchestration |
|---|---|---|
| Bağlılık (coupling) | Gevşek; event-driven | Orta; orchestrator merkezde |
| Debug ve görünürlük | Zor; event spagettisi riski | Yüksek; tek workflow UI |
| Tek hata noktası | Yok; event broker hariç | Orchestrator (HA gerekir) |
| Yeni adım ekleme | Yeni subscriber eklemek yeter | Workflow kodunu değiştirmek gerekir |
| İdeal akış büyüklüğü | 2-3 servis | 4+ servis, koşullu dallanma |
| Cyclic dependency riski | Yüksek | Düşük |
| Test edilebilirlik | Orta; integration test ağır | Yüksek; replay ve mock kolay |
| Tipik gecikme | Düşük; doğrudan event | Orta; orchestrator round-trip |
| Önerilen 2026 framework | Kafka + Outbox + Idempotent consumer | Temporal, Camunda 8, Axon Saga |
Pratik öneri: Üç servisten kısa, dallanma olmayan akışlarda choreography sade kalır. 4+ servisli, koşullu adımlı veya paralel branch’li akışlarda orchestration debug kolaylığı sağlar. Hibrit yaklaşım da yaygındır: üst düzey akış orchestration, bounded context içi olaylar choreography.
2PC/XA vs Saga: Strong Consistency Sonu mu?
2PC ve XA strong consistency sunsa da pratik kısıtlamaları kabul edilemez seviyede. DataDog APM 2026 verisi 2PC tabanlı sistemlerin p99 latency’sinin Saga’ya göre %62 daha yüksek, blocked lock outage süresinin 3.8 kat fazla olduğunu gösteriyor. Pat Helland’ın “Data on the Outside vs Data on the Inside” makalesi 2005’te servis sınırları ötesinde ACID’in imkansızlığını ortaya koymuştu; 2026 üretim pratiği bu argümanı doğruluyor.
| Boyut | 2PC / XA | Saga Pattern |
|---|---|---|
| Tutarlılık modeli | Strong / ACID | Eventual / ACD (no isolation) |
| Kilit süresi | Tüm akış boyunca | Sadece yerel transaction süresi |
| Coordinator çökmesi | Blocking lock; manuel kurtarma | Saga log replay; otomatik |
| P99 latency etkisi | Yavaş katılımcının 2x’i | Sıralı adımların toplamı |
| Heterojen DB desteği | Çok sınırlı (XA driver gerek) | Tam serbest |
| Managed cloud servisleri | Çoğu desteklemez | Tam uyumlu |
| Ölçeklenebilirlik | Düşük; merkezi koordinasyon | Yüksek; bağımsız servisler |
| Test edilebilirlik | Düşük; XA emülasyonu zor | Yüksek; her adım izole test |
| 2026 endüstri benimseme | %8 (azalıyor) | %74 (artıyor) |
2PC hala niş senaryolarda yer bulur: kapalı kurumsal sistemler, mainframe entegrasyonları, regulatory sertifikasyon. Bunların dışında 2026 mimari kararı net: yeni servisler arası akış tasarlıyorsanız varsayılan Saga olmalıdır.
Compensating Action Tasarımı: Saga’nın En Zor Kısmı
Compensating action, dağıtık transaction yönetiminin en çok yanlış uygulanan parçasıdır. Naif yaklaşım “DELETE + INSERT” tarzı tam rollback varsayar; gerçek dünyada compensating action iş kuralı kaynaklı geri alma adımıdır. OrderCreated event’i sonrası gönderilmiş e-posta silinemez; bunun yerine “iptal bildirimi” gönderilir. Cancel adımının kendisi yeni bir forward transaction’dır.
| Forward Adım | Doğru Compensating Action | Geri Alınabilir mi? | Notlar |
|---|---|---|---|
| Order INSERT (status=PENDING) | Order UPDATE (status=CANCELLED) | Evet; semantic | Soft delete; audit trail korunur |
| Inventory REZERVE | Inventory REZERVE_RELEASE | Evet | Reservation TTL ile çift güvence |
| Payment CHARGE | Payment REFUND | Evet; PSP ile | Stripe/Adyen refund API; idempotency key zorunlu |
| Loyalty points kredi | Loyalty points debit | Evet | Negatif bakiye kontrolü gerekli |
| E-posta gönderimi | İptal bildirimi (apology email) | Hayır; pivot | “En iyi çaba özürü” |
| Fiziksel kargo etiketi | Etiket iptali (kargo SLA varsa) | Kısmen | Pickup öncesi mümkün |
| Borsa emri (settled) | Ters emir (reverse trade) | Hayır; pivot | Manuel müdahale gerekli |
| 3. parti API çağrısı | Sağlayıcının cancel endpoint’i | Sağlayıcıya bağlı | Idempotency key + reconciliation |
- Compensable transaction: Geri alınabilir; rollback için compensating action yazılır.
- Pivot transaction: Saga’nın “geri dönüşü olmayan noktası”; sonraki adımlar yalnızca forward recovery ile tamamlanır.
- Retriable transaction: Pivot sonrası adımlar; başarısızlıkta geri dönmek yerine başarana kadar tekrar denenir.
- Idempotency anahtarı: Aynı compensating action’ın iki kez tetiklenmesi durumunda çift refund/çift release oluşmasını engeller.
- Saga timeout: Sonsuza kadar bekleyen adımı kıran üst sınır; tipik 24-72 saat.
Idempotency, Exactly-Once Delivery Yanılgısı ve Outbox Pattern
Mesaj broker’larında “exactly-once” pratik olarak yoktur; doğru hedef “effectively-once” yani at-least-once delivery + idempotent consumer kombinasyonudur. Confluent 2026 raporuna göre üretimde duplicate event oranı %0.3-1.2 arasında; finansal sistemde yıllık milyonlarca dolar etki yaratır. Saga’nın her adımı ve her compensating action idempotency anahtarı taşımak zorundadır.
| Idempotency Gereksinimi | Forward Adım | Compensating Action | Implementasyon |
|---|---|---|---|
| İstemci tarafı anahtar | Zorunlu | Zorunlu | UUID v4 veya request hash |
| Sunucu tarafı dedup penceresi | 24-72 saat | Saga ömrü boyunca | Redis SETNX + TTL veya DB unique index |
| Cached cevap döndürme | Evet | Evet | Aynı response body, audit log |
| Veritabanı yazımı | UPSERT | Idempotent UPDATE | WHERE status_before AND key_unused |
| 3. parti API | Idempotency-Key header | Idempotency-Key header | Stripe/Adyen/Twilio standardı |
| Event yayını | Outbox + offset commit | Outbox + offset commit | Transactional outbox |
| Audit logging | Her tetikleme kaydedilir | Her tetikleme kaydedilir | Append-only; düşürme yok |
Outbox pattern, Saga’nın “dual write problem”ini çözen kritik destekleyici desendir. Yerel transaction içinde hem iş tablosuna hem outbox tablosuna yazılır; ayrı bir relay (Debezium CDC veya custom poller) bu satırları broker’a aktarır. Debezium 2026 raporu outbox uygulayan sistemlerde “lost event” insidentinin %94 azaldığını gösteriyor. Dual write (doğrudan commit + publish) anti-pattern’dir; iki adım arası ağ hatası tutarsızlığı garanti eder. Detay için Outbox Pattern Nedir? rehberi.
Üretim Uygulaması: E-ticaret Sipariş Saga’sı
Tipik e-ticaret sipariş akışı dört servis ve bir orchestrator içerir: Order, Payment, Inventory, Shipping. Saga adımları sırayla çalışır; başarısızlıkta önceki adımların compensating action zinciri tetiklenir. Aşağıdaki Temporal workflow orchestration örneği aynı zamanda Kafka event’leri ile choreography olarak da modellenebilir.
- OrderService: Sipariş kaydı oluşturur (status=PENDING), idempotency key ile OrderCreated event yayınlar.
- PaymentService: Stripe charge API’sini idempotency-key ile çağırır; başarısızlıkta saga PaymentFailed döndürür, Order CANCELLED yapılır.
- InventoryService: Stok rezerve eder (TTL 30 dakika); rezerv başarısızsa PaymentRefunded compensating action zinciri başlatılır.
- ShippingService: Kargo etiketi üretir; etiket üretimi başarısızsa rezerv release + payment refund + order cancel zinciri tetiklenir.
- Saga orchestrator: Temporal workflow ID=”order-{orderId}” ile durumu kalıcı tutar; retry/backoff politikası ve timeout kuralları kodla deklare edilir.
- Pivot transaction: Kargo pickup işleminden sonra geri dönüş yoktur; bu noktadan sonra başarısızlık compensating yerine forward recovery ile çözülür.
- Manuel recovery: Compensating action başarısız olursa saga “manuel müdahale” state’ine düşer; operasyon ekibi audit log üzerinden işlem yapar.
Pratik gözlem: workflow ID’nin iş kuralı bazlı seçilmesi (UUID değil “order-12345”) debug deneyimini dramatik şekilde iyileştirir. Search attributes (customer_id, region, channel) Temporal Web UI veya Camunda Operate’te filtre olarak çalışır ve insident sırasında ilgili saga’ları saniyeler içinde bulma imkanı verir. Bu akış CQRS ve Event Sourcing ile birleştirildiğinde her saga adımı doğal olarak append-only event log üzerinde audit edilebilir hale gelir.
Framework Karşılaştırması: Temporal, Camunda 8, Axon Saga, Eventuate, NServiceBus
2026’da “kendi yaz” yaklaşımı yalnızca trivial 2-3 adımlı akışlarda makul; orta ve büyük akışlarda olgun framework kullanımı zorunluluk. Temporal Replay özelliği workflow logic değişikliklerinde determinism’i doğrulayarak rollout güvenliği sağlar. Camunda 8 “Orchestrate State of Process Automation 2026” raporuna göre BPMN tabanlı orchestration için en geniş kurumsal tabana sahip. Axon Connect ve Eventuate community Java/Spring dünyasında DDD + Saga + Event Sourcing entegre paketi sunuyor.
| Framework | Stil | Dil Desteği | Durum Kalıcılığı | Operasyon Modeli | İdeal Ekip |
|---|---|---|---|---|---|
| Temporal | Orchestration; code-first | Go, Java, TS, Python, .NET, PHP | Cassandra/PostgreSQL/MySQL | Self-hosted + Temporal Cloud | Kod-merkezli, polyglot, SRE |
| Camunda 8 | Orchestration; BPMN-first | Java, Node, Go, Python, .NET | Zeebe broker + ElasticSearch | Self-managed + SaaS | İş analisti + dev iş birliği |
| Axon Saga | Orchestration + event sourcing | Java / Kotlin (Spring) | Axon Server / JPA | Self-hosted + AxonIQ Cloud | DDD + ES odaklı Java ekipleri |
| Eventuate Tram | Choreography + orchestration | Java, Spring | JDBC + CDC (Eventuate Tram) | Self-hosted | Açık kaynak Spring ekipleri |
| NServiceBus Saga | Orchestration; message-driven | .NET (C#, F#) | SQL Server, RavenDB, Azure | Self-hosted + ServicePulse | Enterprise .NET ekipleri |
| AWS Step Functions | Orchestration; JSON state | Dilden bağımsız (Lambda) | AWS managed | Tam serverless | AWS-native, küçük orta akış |
| Apache Airflow + Tasks | Orchestration; batch-friendly | Python | PostgreSQL | Self-hosted + Astronomer | Data pipeline odaklı |
Karar matrisi: Polyglot mikroservis + SRE pratiği olan ekipler için Temporal en güvenli varsayılan. BPMN onayı gereken regüle sektörlerde (sigorta, telco, bankacılık) Camunda 8 doğal seçim. Java/Spring DDD ekipleri Axon Saga ile event sourcing + saga + CQRS’i tek pakette alır. AWS-only küçük ölçekte Step Functions hızlı başlangıç; ancak 4+ servisli karmaşık akışta Temporal’a göre debug sınırlı kalır.
Temporal’ın resmi Saga rehberi, Camunda’nın Saga koordinasyon dokümantasyonu ve Axon Framework’ün Saga dokümantasyonu üretim mimarisi tasarlarken birinci kaynak referanslarıdır.
Hata Senaryoları ve Failure Mode Patterns
Saga’nın gerçek olgunluğu happy path’te değil failure senaryolarında görülür. Çoğu insident eş zamanlı çoklu hata, ağ partition, zombi consumer ve compensating action başarısızlığı kombinasyonundan kaynaklanır.
| Hata Modu | Belirti | Çözüm Deseni |
|---|---|---|
| Geçici servis hatası (5xx) | Adım timeout | Exponential backoff + retry; saga state korunur |
| Kalıcı iş hatası (4xx) | Geçersiz veri | Compensating action zinciri tetiklenir |
| Compensating action çökmesi | Refund API kabul etmiyor | Manuel intervention queue; alert + audit |
| Duplicate message | Aynı event iki kez işlenir | Idempotency key + dedup penceresi |
| Network partition | Adım hem başarılı hem timeout | Idempotent retry + status check |
| Zombi consumer | Eski instance hala işliyor | Consumer group rebalance + heartbeat TTL |
| Saga timeout (uzun bekleme) | Akış 72 saatten uzun | Force compensation veya pivot kararı |
| Out-of-order events | Compensation forward’dan önce | Causal ordering + idempotency |
| Cyclic compensation | A->B->A loop | Saga max retry + circuit breaker |
- Manuel müdahale kuyruğu: Otomatik compensation başarısız olduğunda işlem operasyon ekibine düşer; her saga’nın bu prosedürü olmalı.
- Circuit breaker: Sürekli başarısız adıma istek göndermek yerine kısa süreli devre kesilir, kaynak israfı önlenir.
- Saga max retry: Sonsuz döngüyü engelleyen üst sınır; aşıldığında pivot veya manuel kontrole geçilir.
- Chaos engineering: Production-like ortamda compensation’ın çalışmadığı senaryo simüle edilmeli.
Saga Observability: Replay, Metrics ve Distributed Tracing
Saga’nın görünür olması üretim güvenilirliğinin diğer yarısıdır. Temporal Web UI ve Camunda Operate workflow durumlarını grafik halinde gösterir; stuck workflow, timeout ve compensating action zinciri saniyeler içinde analiz edilebilir. Datadog APM 2026 distributed tracing saga adımlarını otomatik korele eder. Observability: Logs Metrics Traces ile Modern İzlenebilirlik rehberindeki üç sütun saga için de zorunludur.
| Observability Boyutu | Sinyal | Alarm Eşiği | Araç |
|---|---|---|---|
| Saga başarı oranı | completed / started | %99.5 altı | Temporal metrics, Prometheus |
| Ortalama saga süresi | start->complete | SLO + 2 sigma | Datadog APM |
| Compensating action frekansı | compensation/forward oranı | %5 üstü | Custom Grafana panel |
| Stuck workflow sayısı | running > SLA | 0’dan büyük | Temporal advanced visibility |
| Retry oranı per adım | retry_count distribution | p99 > 3 | OpenTelemetry traces |
| Idempotency hit oranı | duplicate detected / total | %5 üstü inceleme | Application metrics |
| Manuel müdahale kuyruğu | pending manual reviews | 0’dan büyük alert | PagerDuty integration |
Replay testi disiplini Temporal versiyonlamasında kritiktir: workflow kodu değiştiğinde geçmiş çalıştırmalar determinism açısından doğrulanır. OpenTelemetry tabanlı distributed tracing forward ve compensating çağrıları aynı trace altında birleştirir; insident response süresi ortalama %58 düşer (Datadog 2026).
Saga’nın Sınırları, Antipattern’ler ve Karar Çerçevesi
Saga her şey için doğru çözüm değildir. Read-your-writes garantisi gereken senaryolarda Saga tek başına yetersiz; eventual consistency’nin “stale read” penceresi kullanıcı deneyimini bozar. Bu durumda consistent read pattern (session-level routing, primary-only okuma, read replica gecikme kontrolü) eklenmelidir. CAP teoremi bağlamında Saga AP tarafında konumlanır; CP gerektiren çift girişli muhasebe, hesap mutabakatı ve regulatory audit zorunluluğu olan senaryolar için ek doğrulama katmanı zorunludur. Hexagonal Architecture ile birleştirildiğinde saga koordinasyonu domain core’dan ayrılır ve test edilebilirlik artar.
- Antipattern: Distributed monolith: Sıkı sınkron HTTP zinciri + ortak veritabanı + saga eklemek; servisler hala lock’ta birbirine bağlı.
- Antipattern: Compensating action olmayan saga: Sadece forward; başarısızlıkta sessizce veri tutarsız kalır.
- Antipattern: Idempotency olmayan retry: Çift refund, çift envanter rezervi, çift e-posta.
- Antipattern: Saga orchestrator iş mantığı yığını: Tüm validation, hesaplama orchestrator’da; servisler anemic.
- Antipattern: Choreography spagettisi: 7+ servis arasında event subscription grafiği; debug imkansız.
Saga maliyet boyutu: Temporal Cloud workflow başına ortalama 0.012 USD aylık; self-hosted Camunda 8 küçük ölçekte 600-800 USD/ay operasyon yükü getirir. Bu maliyet 2PC migrasyonu sonucu kazanılan uptime, daha düşük p99 latency ve heterojen DB esnekliği ile kolayca amorti edilir; ortalama ROI 6-9 ay arasında. Modular Monolith aşamasından gelen ekipler için Saga, mikroservise geçişin doğal bir parçasıdır; DDD ile Kurumsal Yazılım Mimarisi‘nde tanımlanan bounded context sınırları saga adımlarının doğal sınırlarıdır. Service Mesh katmanı saga için retry, timeout ve circuit breaker disiplinini transparent şekilde sağlar.
Sık Sorulan Sorular
Saga Pattern her mikroservis akışı için zorunlu mu?
Hayır. Tek servisin yerel ACID transaction’ı ile tamamlanan akışlarda saga gereksiz karmaşıklıktır. Saga, iki veya daha fazla servisin aynı iş işlemine veri yazması gereken durumlarda devreye girer. Yalnızca okuma (read aggregation) gerektiren akışlarda saga değil, gateway aggregation veya BFF pattern daha uygundur. Saga karar kuralı basittir: birden fazla servis veri değiştiriyor mu? Yanıt evetse saga; hayırsa lokal transaction yeterli.
Compensating action her zaman teknik olarak mümkün mü?
Hayır. E-posta gönderimi, fiziksel kargo teslimatı, borsa işlemi gibi geri alınamaz adımlar pivot transaction olarak modellenir; saga bu adımdan önce başarısızlığa düşürülür veya sonrası için forward recovery uygulanır. Microsoft Architecture Center bu yaklaşımı “pivot transaction” olarak adlandırır ve saga akışının kritik geri alınamaz adımdan önce konumlandırılmasını önerir. Pratikte e-posta iptali için “iptal bildirimi” gönderilir; bu yeni bir forward transaction’dır, gerçek bir geri alma değildir.
Saga ile event sourcing aynı şey mi, birlikte kullanılır mı?
Hayır, farklı kavramlardır. Saga bir koordinasyon pattern’idir, event sourcing ise veri depolama pattern’idir. İkisi birlikte kullanıldığında güçlü bir kombinasyon oluşur; event sourcing saga log için doğal kalıcılık katmanı sağlar, audit trail otomatik olarak gelir. Confluent 2026 raporu Kafka tabanlı sistemlerde event sourcing + saga kombinasyonunun replay edilebilir debug ve regulatory audit için %71 ekip tarafından tercih edildiğini gösteriyor. Axon Framework bu kombinasyonu tek pakette sunar.
Idempotency anahtarı nasıl üretilir ve ne kadar saklanır?
Stripe ve AWS API Gateway pratiğine göre idempotency anahtarı istemci tarafından üretilen UUID v4 veya iş ihtiyacına özgü deterministik hash olmalıdır. Sunucu bu anahtarı en az 24, tipik olarak 72 saat saklar ve aynı anahtarla gelen istek için cached cevabı döner. Saga adımlarının her biri için ayrı anahtar üretilmeli; compensating action’lar da kendi idempotency anahtarına sahip olmalı, aksi halde retry sırasında çift compensation oluşabilir. Redis SETNX + TTL veya veritabanı unique index pratik implementasyon seçenekleridir.
Temporal mı Camunda 8 mi tercih edilmeli?
Temporal kod-merkezli polyglot ekipler için, Camunda 8 ise BPMN diyagramı ve iş analisti iş birliği gereken regüle senaryolar için uygundur. Temporal Cloud yönetilen hizmettir, operasyonel yükü düşürür ve replay testleri ile production rollout güvenliği sunar. Camunda 8 self-hosted’da daha esnektir ve görsel BPMN sürecinin iş tarafıyla paylaşılması gereken sigorta, bankacılık, telco sektörlerinde fark yaratır. CNCF 2026 anketinde Temporal benimseme oranı %38, Camunda 8 %29 düzeyinde; iki framework de “Adopt” konumundadır.
Sonuç: 2026’nın Pattern Hükmü
Saga Pattern, 2026 yılında mikroservis mimarilerinde dağıtık transaction yönetiminin endüstri standardıdır. 2PC ve XA modelleri pratik olarak tükendi; Saga ise eventual consistency disiplini, idempotent adımlar, outbox pattern destekli güvenli event yayını ve olgun orchestration framework’leri (Temporal, Camunda 8, Axon Saga) ile üretim sınıfı çözüm sunuyor. Orchestration karmaşık ve dallanmalı akışlarda debug avantajı sağlar; choreography ise sade küçük akışlarda gevşek bağlılık sunar. Üretim olgunluğunun anahtarları: her adımın idempotency garantisi, compensating action’ların manuel müdahale prosedürüne bağlanması, pivot transaction’ların doğru konumlandırılması, replay testi disiplini ve OpenTelemetry tabanlı distributed tracing. Pattern verdict: 4 servisten fazla içeren akışta orchestration (Temporal varsayılan), 2-3 servisli sade akışta choreography + outbox, regüle BPMN dünyasında Camunda 8 — ve her senaryoda idempotency anahtarı zorunlu.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.