Orchestration vs Choreography: Asenkron Sistemlerde Hangisi Gerçekten Çalışır

Bir e-ticaret sisteminde sipariş verdikten sonra neler olur? Ödeme doğrulanır, stok azalır, kargo hazırlanır, müşteriye bildirim gönderilir. Monolitik bir uygulamada bu adımlar sırayla çalışır ve kontrolü kolaydır. Ama microservice mimarisine geçtiğinde her adım ayrı bir serviste yaşıyor ve aralarında senkronizasyon sorunu ortaya çıkıyor. burada orchestration ve choreography devreye giriyor; ikisi de aynı problemi farklı şekilde çözüyor.

Orchestration, merkezi bir "orkestra şefi" gibi çalışır. Sipariş servisi, ödeme servisiyle konuşur, sonra stok servisiyle, sonra kargo servisiyle. Her adım sırayla ve kontrollü bir şekilde ilerler. Bir merkezi koordinatör (örneğin Saga pattern'i kullanan bir servis) tüm akışı yönetir. Eğer ödeme başarısız olursa, orkestra şefi bunu bilir ve geri alma işlemini başlatır.

Choreography ise hiçbir merkezi kontrolcü olmaksızın çalışır. Her servis, belirli olayları dinler ve kendi işini yapar. Ödeme servisi başarılı olduğunda bir olay yayınlar, stok servisi bu olayı dinler ve stoku azaltır, ardından kendi başarısını yayınlar. Domino etkisi gibi, her servis bir öncekinin başarısını dinleyerek harekete geçer.

Orchestration'ın Gerçek Avantajı: Kontrol ve Hata Yönetimi

Orchestration'ın en büyük üstünlüğü akışı görebilmektir. Koordinatör servisi, tüm adımları bilinçli bir şekilde yönetir ve hata durumunda ne yapacağını bilir. Bir ödeme başarısız olursa, sipariş servisi bunu hemen fark eder ve kullanıcıya yanıt verebilir. Ayrıca, yeni bir gereksinim eklemek (örneğin bir üçüncü taraf API'yi çağırmak) tek bir yerde yapılır.

Ancak burada bir tuzak var: orchestrator servisi bir darboğaz haline gelebilir. Tüm işler onun üzerinden geçtiği için, eğer bu servis yavaşsa veya hata yaparsa, tüm sistem etkilenir. Ayrıca, orchestrator'ın kendisi de kompleks hale gelir; çok fazla mantık taşıyabilir.

Choreography'nin Özgürlüğü ve Fiyatı

Choreography'de merkezi bir koordinatör olmadığı için, her servis bağımsız olarak çalışır. Bu ölçeklenebilirliği artırır ve bir servisteki yavaşlama diğerlerini doğrudan etkilemez. Ayrıca, yeni bir servisi sisteme eklemek daha kolaydır; sadece ilgili olayları dinlemesini sağlarsın.

Ama burada ciddi bir sorun var: hata takibi ve geri alma işlemleri karmaşık hale gelir. Eğer kargo servisi başarısız olursa, bu bilgi ödeme servisiyle nasıl iletişim kuracak? Tüm akışı izlemek zor olur. Distributed tracing olmadan, sistemi hata ayıklamak kabus haline gelebilir.

Pratik Tavsiye

Gerçek dünyada, ikisini de kullanmak en akıllıca seçimdir. Kritik ve sırayla yapılması gereken işler (ödeme, stok) için orchestration kullan. Bildirimleri gönderme, analitik kaydetme gibi yan işler için choreography yeterli olur. Hibrid bir yaklaşım, her iki dünyanın da avantajını sağlar.

Orchestration'ı seçersen, orchestrator servisiyle ilgili monitoring ve failover stratejisine odaklan. Choreography'yi seçersen, distributed tracing ve event sourcing'i iyi kurmadan başlama. Başarısız işleri yeniden deneme mekanizması ve dead letter queue'ler olmadan bu mimarilerin hiçbiri güvenilir olmaz.