Event Driven Mimari Ne Zaman Tercih Edilmelidir

Dağıtık sistemler ve mikroservisler yaygınlaştıkça "event driven mimari" terimi de yazılım dünyasında sıkça duyulan kavramlardan biri haline geldi. Ancak her mimari yaklaşım gibi bunun da uygun olduğu durumlar kadar uygun olmadığı durumlar var. Bu yazıda event driven mimarinin ne olduğunu, hangi senaryolarda gerçek bir fayda sağladığını ve hangi durumlarda gereksiz bir karmaşıklığa dönüştüğünü pratik kriterlerle ele alacağız.

Event Driven Mimari Nedir?

Event (olay), bir sistemde gerçekleşen bir durum değişikliğinin kaydıdır. Örneğin bir siparişin oluşturulması, bir kullanıcının kaydolması veya bir ödemenin tamamlanması birer olaydır. Event driven mimaride sistemler, bu tür durum değişikliklerini birbirine doğrudan çağrı yaparak değil, olayları yayınlayarak (publish) iletir.

Klasik istek-yanıt (senkron) mimaride bir bileşen başka bir bileşeni çağırır ve işlemin tamamlanmasını, yani yanıtı bekler. Çağıran taraf, çağrılan tarafın cevap vermesine kadar bloklanır veya en azından o işlemin sonucuna bağımlı kalır. Event driven yaklaşımda ise durum farklıdır: bir bileşen "şu olay gerçekleşti" bilgisini yayınlar ve bu olayla ilgilenen taraflar, kendi zamanlamalarına göre bu olayı işler. Olayı üreten taraf (producer), bu olayı kimin, ne zaman ve nasıl işleyeceğiyle ilgilenmez.

Bu noktada üretici ve tüketici (consumer) rolleri birbirinden habersiz çalışır. Üretici yalnızca bir olayın gerçekleştiğini bildirir; tüketiciler ise bu olaylara abone olup kendi iş mantıklarını buna göre yürütür. Bu ayrım, mimarinin temel karakterini oluşturur ve ilerleyen bölümlerde değineceğimiz avantaj ve dezavantajların da kaynağıdır.

Olayların Aktarımı ve Gevşek Bağlılık

Event driven mimaride olaylar genellikle doğrudan bir bileşenden diğerine değil, aradaki bir aracı yapı üzerinden iletilir. Bu aracı, bir mesaj kuyruğu veya olay akışı (event broker) şeklinde düşünülebilir. Üretici, olayı bu aracıya gönderir; tüketiciler de yine bu aracıdan ilgilendikleri olayları alır.

Bu dolaylı iletişim modelinin getirdiği en önemli sonuç, üretici ile tüketicinin birbirinin iç yapısını bilmesine gerek kalmamasıdır. Üretici, olayı kaç tüketicinin dinlediğini, bu tüketicilerin hangi teknolojiyle yazıldığını veya hangi hızda çalıştığını bilmek zorunda değildir. Benzer şekilde yeni bir tüketici sisteme eklendiğinde, üretici tarafında herhangi bir değişiklik yapılmasına gerek kalmaz.

Bu gevşek bağlılık (loose coupling), bileşenlerin birbirinden bağımsız olarak geliştirilmesine ve dağıtılmasına (deploy edilmesine) imkan tanır. Bir ekip kendi servisini güncellerken diğer ekiplerin servislerini bozma riski azalır, çünkü aradaki bağlantı doğrudan bir fonksiyon çağrısı değil, tanımlı bir olay formatıdır. Bu özellik, özellikle birden fazla ekibin bağımsız çalıştığı büyük sistemlerde değerli hale gelir.

Event Driven Mimarinin Gerçek Fayda Sağladığı Senaryolar

Event driven mimarinin asıl değeri, belirli sistem özellikleriyle bir araya geldiğinde ortaya çıkar. Bunlardan ilki, asenkron iş yüklerinin yoğun olduğu sistemlerdir. Sipariş işleme sürecini örnek alalım: bir sipariş oluşturulduğunda stok güncellemesi, fatura oluşturma, bildirim gönderimi gibi birçok adım tetiklenebilir. Bu adımların tamamının aynı anda, sipariş oluşturma isteğine yanıt verilmeden önce senkron şekilde tamamlanması gerekmez. Sipariş oluşturuldu olayı yayınlanır, ilgili servisler bu olayı kendi hızlarında işler.

İkinci önemli senaryo, sistem bileşenlerinin farklı yük altında bağımsız ölçeklenmesi gereken durumlardır. Örneğin bildirim gönderimi yapan bir servis, yoğun kampanya dönemlerinde çok daha fazla işlem yapmak zorunda kalabilir. Bu servisin diğer servislerden bağımsız olarak ölçeklenebilmesi, event driven yapının getirdiği pratik bir avantajdır.

Üçüncü senaryo, gerçek zamanlıya yakın veri akışı ve aynı olayın birden fazla tüketici tarafından işlenmesi gereken durumlardır. Bir kullanıcı etkinliği (örneğin bir ürünün görüntülenmesi) hem analitik sisteme, hem öneri motoruna hem de loglama sistemine aynı anda iletilmek istenebilir. Bu, tek bir olayın çoklu tüketici tarafından bağımsız şekilde işlenmesine olanak tanıyan event driven modelin tipik kullanım alanlarından biridir.

Son olarak, yüksek trafik dalgalanmalarının olduğu sistemlerde event driven mimari bir tampon görevi görebilir. Olaylar bir kuyrukta biriktirilip tüketiciler tarafından kendi kapasitelerine göre işlenebildiği için, ani yük artışlarında sistemin tamamen çökmesi yerine daha kontrollü bir yavaşlama yaşanması mümkün olur.

Event Driven Mimarinin Gereksiz Karmaşıklık Yarattığı Durumlar

Bu avantajlara rağmen event driven mimari her sistem için doğru tercih değildir. Basit CRUD (oluşturma, okuma, güncelleme, silme) uygulamalarında, asenkron bir akış kurmanın getirdiği ek maliyet çoğu zaman sağladığı faydayı aşar. Kullanıcının bir formu doldurup kaydettiği ve hemen sonucu görmesi gereken basit bir yönetim panelinde, olay tabanlı bir dolaylama katmanı eklemek yalnızca gereksiz gecikme ve karmaşıklık getirir.

Güçlü tutarlılık (strong consistency) gereksinimi olan sistemler de dikkatli değerlendirilmelidir. Event driven mimaride yaygın olan model, "eventual consistency" yani olayların işlenmesinin ardından zamanla tutarlı hale gelen bir veri durumudur. Bir bankacılık işleminde veya stok miktarının anlık olarak kesinlikle doğru olması gereken bir senaryoda, bu gecikmeli tutarlılık ciddi riskler doğurabilir. Böyle durumlarda senkron, doğrudan işlem garantisi veren yaklaşımlar daha güvenlidir.

Küçük ekipler için de bu mimarinin getirdiği operasyonel yük göz ardı edilmemelidir. Olay aracısının (broker) kurulumu, izlenmesi, olayların şema yönetimi, hata senaryolarının ele alınması gibi konular, dağıtık sistemler konusunda deneyimi sınırlı veya kaynak olarak kısıtlı ekiplerin altından kalkmasını zorlaştırabilir. Bu durumda mimarinin sağladığı esneklik, günlük operasyonel yükün altında kaybolabilir.

Dikkat Edilmesi Gereken Zorluklar

Event driven mimariyi tercih etmeden önce göz önünde bulundurulması gereken bazı teknik zorluklar vardır. Bunlardan ilki hata ayıklamadır (debugging). Senkron bir çağrı zincirinde bir hatayı izlemek nispeten kolaydır; çağrı sırası bellidir. Ancak asenkron olay akışlarında bir olayın hangi sırayla, hangi servisler tarafından işlendiğini takip etmek daha zordur, özellikle hata birden fazla adım sonra ortaya çıktığında.

Bu nedenle izlenebilirlik (tracing), event driven sistemlerde kritik bir gereksinim haline gelir. Olayların hangi üretici tarafından oluşturulduğunu, hangi tüketiciler tarafından ne zaman işlendiğini görebilmek için ek araçlara ve pratiklere ihtiyaç duyulur. Bu altyapı kurulmadan event driven mimariye geçmek, üretim ortamında sorun yaşandığında kök nedeni bulmayı ciddi şekilde zorlaştırabilir.

Olayların sıralaması ve tekrar işlenmesi (idempotency) de tasarımda öncelikli ele alınması gereken konulardandır. Bir olay ağ sorunları nedeniyle birden fazla kez iletilebilir veya sıralama bazı durumlarda garanti edilmeyebilir. Tüketici servislerin, aynı olayı birden fazla kez işlese bile sistemde yanlış bir sonuç oluşturmayacak şekilde (idempotent) tasarlanması gerekir. Bu, event driven mimariye geçerken baştan planlanması gereken bir tasarım ilkesidir, sonradan eklenmesi zor bir özellik değildir.

Hibrit Yaklaşım: Senkron ve Event Driven Mimarinin Birlikte Kullanımı

Pratikte çoğu sistem tamamen senkron ya da tamamen event driven olmak zorunda değildir. Kritik ve anlık yanıt gerektiren işlemler için senkron çağrılar korunabilir. Örneğin bir kullanıcının giriş yapması veya bir ödemenin onaylanması gibi, sonucun hemen kullanıcıya iletilmesi gereken işlemler senkron akışta kalmaya devam edebilir.

Buna karşılık, gecikmeye toleranslı ve arka planda işlenebilecek görevler event driven akışa taşınabilir. Bildirim gönderimi, raporlama, analitik veri toplama, e-posta gönderimi gibi işlemler kullanıcının anlık deneyimini etkilemeden asenkron olarak gerçekleştirilebilir.

Bu iki yaklaşımın aynı sistem içinde farklı katmanlarda bir arada bulunması oldukça yaygın bir pratiktir. Örneğin bir e-ticaret sisteminde sipariş oluşturma isteği senkron bir API çağrısıyla işlenirken, bu işlemin ardından tetiklenen stok güncelleme, bildirim ve raporlama adımları event driven bir akışla yürütülebilir. Bu hibrit model, her iki yaklaşımın güçlü yönlerinden faydalanmayı mümkün kılar.

Karar Verirken Değerlendirilmesi Gereken Kriterler

Event driven mimariye geçip geçmeme kararı, tek bir teknik özelliğe değil, birden fazla faktörün birlikte değerlendirilmesine dayanmalıdır.

İlk kriter, ekibin dağıtık sistemler ve asenkron mimariler konusundaki tecrübe düzeyidir. Bu mimariyi daha önce üretim ortamında deneyimlememiş bir ekip için, öğrenme eğrisi ve olası hatalar göz önünde bulundurulmalıdır.

İkinci kriter, sistemin mevcut ve beklenen ölçeğidir. Küçük veya orta ölçekli, trafik tahmini yapılabilir bir sistem için event driven mimarinin getirdiği karmaşıklık çoğu zaman gereksizdir. Ancak büyüme beklentisi yüksek, bileşenlerin bağımsız ölçeklenmesi gereken sistemlerde bu yatırım zamanla karşılığını verebilir.

Üçüncü kriter, veri tutarlılığı gereksinimlerinin ne kadar katı olduğudur. Eğer sistemin belirli bölümleri kesin ve anlık tutarlılık gerektiriyorsa, bu bölümler senkron yaklaşımla korunmalı, event driven mimari daha toleranslı olan diğer bölümlere uygulanmalıdır.

Son olarak, operasyonel ve izleme altyapısının bu karmaşıklığı destekleyip desteklemediği değerlendirilmelidir. Olay aracısının izlenmesi, hata yönetimi, tracing altyapısı gibi unsurlar hazır değilse, event driven mimariye geçiş öncesinde bu altyapının kurulması gerekir. Aksi halde mimarinin teorik avantajları, pratikte yönetilemeyen bir karmaşıklığa dönüşebilir.

Sonuç olarak event driven mimari, doğru senaryoda uygulandığında ölçeklenebilirlik, esneklik ve bileşenler arası bağımsızlık sağlayan güçlü bir yaklaşımdır. Ancak her sistem için varsayılan tercih olmamalı; sistemin gerçek ihtiyaçları, ekibin kapasitesi ve veri tutarlılığı gereksinimleri dikkatle değerlendirildikten sonra tercih edilmelidir.