Event-Driven Mimari Nedir? Olay Güdümlü Sistemler Basitçe

Event-driven mimari nedir?

Event-driven mimari (olay güdümlü mimari), yazılım bileşenlerinin birbirini doğrudan çağırmak yerine olay yayınladığı ve olaylara tepki verdiği tasarım yaklaşımıdır. Örneğin sipariş servisi "yeni sipariş geldi" olayını duyurur. Stok, fatura ve bildirim bileşenleri bu olayı dinler. Böylece gönderen, kimin dinlediğini bilmek zorunda kalmaz.

Kısacası bu mimaride bileşenler birbirine "şunu yap" demez, "şu oldu" der. Ardından ilgilenenler kendi kararını verir. Yani bu küçük fark, sistemin büyümesini ve değişmesini çok kolaylaştırır.

Bu yazıda event-driven mimari nedir sorusuna kavram düzeyinde bakıyoruz. Kod bloğu yok; yalnızca mantığı, kullanım alanlarını, faydaları ve sınırları göreceksiniz. Ekibimiz yazılım projelerinde bu tartışmayla sık karşılaştığı için örnekleri bilerek sade tuttuk; çünkü terimi önce sezgiyle kavramak, sonra ayrıntıya inmek en sağlam yoldur.

Event-driven mimari nedir, bir pano benzetmesiyle nasıl kavrarsınız?

Bir restoran mutfağı düşünün. Garson siparişi alır ve her ustaya tek tek söylerse, mutfak garsonun hızına bağımlı olur. Üstelik yeni bir tezgâh eklendiğinde garsonun iş akışı da değişir. Bu, doğrudan çağrı mantığıdır.

Peki farklı bir düzen kursanız ne olur? Garson sipariş fişini mutfaktaki panoya asar. Örneğin ızgara ustası kendi satırını görür ve hazırlar. Tatlı ustası kendi işini alır. Ardından kasa fişi görünce hesabı hazırlar.

Burada garson, kimin okuyacağını bilmez. Panoya yeni bir tezgâh eklenirse bile garsonun alışkanlığı değişmez. İşte bu pano, yazılımdaki aracıya (broker) denk gelir. Fiş ise olayın kendisidir, yani olmuş bir şeyin yazılı kaydıdır.

Benzetmenin sınırını da bilmek gerekir. Ancak gerçek sistemde fiş kaybolabilir, iki kez okunabilir ya da yanlış sırayla görülebilir. Yazının ilerleyen bölümleri tam olarak bu sorunlara bakıyor. Böylece benzetmenin neresinin gerçeğe uyduğunu, neresinin uymadığını net görürsünüz.

Olay, komut ve mesaj arasındaki fark nedir?

Üç kelime sık karışır. Ancak aralarındaki fark, tasarımın sağlıklı olup olmadığını belirler.

• Olay (event): Olmuş bir şeyin kaydıdır. Adını geçmiş zamanla yazarsınız, örneğin "ödeme geldi". Olayı geri almazsınız; düzeltmek için yeni bir olay yayınlarsınız.
• Komut (command): Bir işin yapılmasını isteyen çağrıdır, örneğin "faturayı oluştur". Genellikle tek bir alıcıya gider.
• Mesaj (message): İkisini de taşıyabilen genel zarf kavramıdır. Olay da komut da bir mesaj olarak yolculuk eder.

Ekipler çoğu zaman olay adını taşıyan gizli komutlar yazar. "Faturayı oluştur olayı" buna iyi bir örnektir. Bu durumda gönderen, alıcıdan bir şey bekliyordur ve gevşek bağlılık sessizce çöker.

Kısacası pratik bir kural var. Olayı, gönderenin kendi alanında olan bitenin duyurusu olarak yazın. Örneğin "stok güncelle" yerine "ürün satıldı" demek daha doğrudur. Çünkü ilki alıcıya iş verir, ikincisi yalnızca durumu bildirir. Tepkiyi ise alıcıya bırakın; böylece gönderen sade kalır.

Üretici, aracı ve tüketici ne iş yapar?

Her event-driven sistem üç role dayanır. Rollerin adı kaynaktan kaynağa değişir, ancak mantık aynı kalır. Üstelik bu roller küçük bir sistemde tek bir uygulamanın içinde bile bulunabilir.

• Üretici (producer): Bir şeyin olduğunu fark eden ve bunu olay olarak yayınlayan bileşendir. Örneğin sipariş servisi.
• Aracı (broker, olay kanalı ya da yönlendirici): Olayları alır, gerekirse saklar ve doğru yere ulaştırır.
• Tüketici (consumer): Olayı alıp kendi işini yapan bileşendir. Örneğin stok ya da bildirim servisi.

Bu üçlü, büyük bulut sağlayıcılarının mimari belgelerinde de aynıdır. Microsoft Azure Architecture Center üretici, tüketici ve olay kanalı der. AWS ise üretici, yönlendirici ve tüketici terimlerini kullanır.

Dolayısıyla bir araç ya da servis seçerken adlara değil rollere bakın. Pazarlama dilindeki ürün adları sık değişir, roller ise değişmez. Hangi bileşen yayınlıyor, hangisi taşıyor, hangisi tepki veriyor? Örneğin bir ödeme servisi bir akışta üretici, başka bir akışta tüketici olabilir. Bu üç soruyu yanıtlayabiliyorsanız şemayı okuyabilirsiniz. Böylece yeni bir aracın belgesi size yabancı gelmez.

Yayınla-abone ol modeli nasıl çalışır?

Yayınla-abone ol (publish-subscribe) modelinde üretici olayı bir konuya (topic) ya da kanala yayınlar. Ardından tüketiciler o konuya abone olur. Olay yayınlandığında aracı, her aboneye bir kopya gönderir.

Burada üretici, abonelerin kim olduğunu bilmez. Bu tasarım, haber bülteni mantığına benzer: yayıncı bülteni gönderir, okurun ne yaptığına bakmaz. Üstelik aboneler birbirinden de habersizdir. Her biri olayın kendi kopyasını görür ve kendi hızında işler.

Microsoft belgesi önemli bir ayrıntıyı vurgular: bu modelde aracı, olayı teslim ettikten sonra kalıcı bir günlükte tutmaz. Dolayısıyla sonradan abone olan biri geçmiş olayları göremez. Bu nedenle geçmişi yeniden okumanız gerekiyorsa başka bir model gerekir.

Örneğin "yeni sipariş" konusuna fatura, stok ve bildirim servisi abone olur. Bir gün raporlama ekibi de abone olmak isterse sipariş koduna dokunmanız gerekmez. Yalnızca yeni bir abonelik tanımlarsınız.

Olay akışı (event streaming) kuyruktan ve yayınla-abone ol modelinden farklı mıdır?

Olay akışında aracı, olayları kalıcı bir günlüğe (log) sırayla yazar. Tüketici abone olmaz; günlüğü kendisi okur ve nerede kaldığını kendisi takip eder. Böylece geriye sarabilir, yeni gelen biri en baştan okuyabilir.

Microsoft belgesine göre bu yapı, hata sonrası kurtarma, geç gelen tüketiciler ve düzeltmeden sonra yeniden işleme senaryolarını destekler. Sıra ise bölüm (partition) içinde kesindir.

Kuyruk modeli ise farklı çalışır. Birden çok tüketici aynı kuyruktan mesaj çeker ve her mesajı hata yoksa yalnızca biri işler. Yani kuyruk iş dağıtır, yayınla-abone ol ise haber dağıtır.

• Aynı olayı birden çok bileşenin görmesi gerekiyorsa yayınla-abone ol modeli uygundur.
• Her işi tek bir işçinin alması gerekiyorsa kuyruk modeli uygundur.
• Geçmişi yeniden oynatmak istiyorsanız olay akışı modeli uygundur.

Event-driven mimari ile istek-yanıt mimarisi arasındaki fark nedir?

Klasik istek-yanıt modelinde bir bileşen diğerini çağırır ve cevabı bekler. Event-driven modelde ise bir bileşen olayı bırakır ve yoluna devam eder. Bu nedenle aşağıdaki tablo farkı yan yana gösteriyor.

Hangisi daha iyi diye sormayın. Çünkü ikisi aynı sistemde birlikte yaşar. Örneğin ürün sayfasını gösterirken istek-yanıt kullanırsınız, sipariş sonrası işleri ise olaylara bırakırsınız.

E-ticaret siparişi event-driven mimaride nasıl akar?

Aşağıdaki akış bir örnek senaryodur; gerçek bir müşteriyi ya da sonucu anlatmaz. Küçük bir online mağazada sipariş verildiğini düşünelim.

1. Önce müşteri siparişi onaylar. Sipariş servisi kaydı açar ve "yeni sipariş" olayını yayınlar.
2. Stok servisi olayı alır, ürünleri ayırır ve "stok hazır" olayını yayınlar.
3. Ödeme servisi tahsilatı dener. Başarılı olursa "ödeme geldi" olayı çıkar.
4. Ardından bildirim servisi müşteriye onay e-postası gönderir.
5. Kargo ve fatura servisleri "ödeme geldi" olayını görünce kendi işlerini başlatır.

Ödeme başarısız olursa servis "ödeme başarısız" olayını yayınlar. Stok servisi bu olayı görünce ayırdığı ürünleri serbest bırakır. Microsoft belgesi bu yaklaşıma telafi edici işlem (compensating transaction) adını verir.

Tek bir yere yazdığınız uzun bir sipariş fonksiyonu yok. Bunun yerine küçük, bağımsız tepkiler var; dolayısıyla her parçayı ayrı ayrı test edebilirsiniz. Ödeme altyapısını seçerken sanal pos ve online ödeme altyapısı rehberimize de göz atabilirsiniz.

Event-driven mimari neden gevşek bağlılık sağlar?

Gevşek bağlılık (loose coupling), bir bileşeni değiştirirken diğerlerini değiştirmek zorunda kalmamaktır. Yani üretici yalnızca olayı yayınlar. Tüketicilerin sayısını, adını ya da işini bilmez.

Microsoft belgesi bunu şöyle özetler: noktadan noktaya entegrasyon yoktur ve yeni tüketiciler, üreticiyi ya da diğer tüketicileri değiştirmeden eklenebilir. Bu özellik, ekipler arası çalışmada büyük rahatlık getirir. Event-driven mimari nedir diye merak edenlerin en çok ilgisini çeken yön de budur: bir ekip diğerinin yayın takvimini beklemeden yeni bir tüketici ekleyebilir.

Bununla birlikte "sıfır bağlılık" yoktur. Çünkü olayın biçimi, tüm taraflar için ortak bir sözleşmedir. Üretici olayın alanlarını değiştirirse tüketiciler bozulabilir. Bu yüzden olay şemasına sürüm vermek gerekir.

Bağımsız geliştirme ve yayınlama fikri ön yüzde de vardır. Micro frontend yaklaşımı bunun iyi bir örneğidir. Ekipler ayrıca şunu da sever: yeni bir tüketiciyi güvenle açmak için özellik bayrağı (feature flag) kullanmak da işinizi kolaylaştırır.

Ölçek ve dayanıklılık açısından hangi faydaları sunar?

AWS belgesi, üretici ve tüketici servislerin birbirinden bağımsız ölçeklenebildiğini, güncellenebildiğini ve yayınlanabildiğini söyler. Bunun günlük hayattaki karşılığı ise çok somuttur.

• Ani yük: Kampanya anında siparişler aracıda birikir. Tüketiciler kendi hızında işler, sistem çökmez. Yani yoğunluk ani bir arızaya değil, kısa bir gecikmeye dönüşür.
• Hata izolasyonu: Bildirim servisi çökerse sipariş alımı durmaz. Olaylar bekler, servis dönünce de sırayla ilerler.
• Bağımsız ölçek: Yalnızca yoğun çalışan tüketicinin kopya sayısını artırırsınız.
• Sorgulama yükü: Tüketiciler beklemek yerine olay geldiğinde çalışır. AWS bunu, sürekli sorgulama için ödeme yapmamak diye anlatır.

Ancak bu fayda otomatik gelmez. Çünkü aracının kendisi de bir bileşendir ve işletilmesi gerekir. Önbellek gibi okuma yükünü azaltan çözümleri de unutmayın; Redis ve Memcached karşılaştırmamız bu konuyu ayrıca ele alıyor.

CloudEvents nedir ve olay biçimini neden standartlaştırır?

CloudEvents, olay verisinin biçimini tanımlayan, sağlayıcıdan bağımsız bir belirtimdir. Proje, CNCF (Cloud Native Computing Foundation) çatısı altında yer alır. Amaç, farklı servislerin ve araçların olayları ortak bir zarfla anlatmasıdır.

Belirtimin resmi metni dört zorunlu bağlam özniteliği sayar: id, source, specversion ve type. Yani her olay bir kimlik, bir kaynak, bir sürüm ve bir tür taşır.

Ancak önemli bir ayrıntı daha var. Belirtim, teslim garantisi gibi taşıma davranışlarını anlatmaz. Yani bunlar kullandığınız protokole ve araca bağlıdır. Dolayısıyla "CloudEvents kullanıyoruz, olaylar kaybolmaz" demek yanlıştır.

Pratikte bu standart iki şeye yarar. İlk olarak olayları farklı sistemler arasında taşırken ortak bir dil sağlar. Ayrıca id alanı tekrar eden olayı tanımanıza yardım eder.

Olay yükü (payload) ne kadar bilgi taşımalı?

Olay tasarlarken sık sorulan soru şudur: olay her şeyi mi taşısın, yoksa yalnızca bir anahtar mı? Microsoft belgesi iki yaklaşımı da tarif eder.

• Tüm bilgiyi taşımak: Tüketici başka bir yere sormadan çalışır. Buna karşılık olay büyür, sözleşme karmaşıklaşır ve güncellemeden sonra tutarsız veri riski doğar.
• Yalnızca anahtarı taşımak: Tüketici gerisini kaynaktan çeker. Veri tek yerden gelir, ancak kaynağa sürekli sorgu gider.

Hangisini seçeceğiniz ise tüketicilerin ihtiyacına bağlıdır. Hatta aynı sistemde ikisini karıştırabilirsiniz. Yine de bir kuralı sabit tutun: olaya gereğinden fazla hassas veri koymayın.

Birçok bileşen olayı görebilir, hatta onu tüketmesi gerekmeyenler bile. Bu nedenle kişisel veriyi, parolayı ya da ödeme ayrıntısını olaya yazmak yerine bir referans taşıyın.

Nihai tutarlılık günlük işte ne anlama gelir?

Nihai tutarlılık (eventual consistency), verinin tüm yerlerde aynı anda değil, kısa bir gecikmeyle aynı hale geldiği anlamına gelir. Üretici bir değişikliği duyurduğunda tüketiciler bunu kendi hızında işler. Böylece arada kısa bir pencere oluşur.

Örneğin müşteri siparişi verir. Sipariş ekranı hemen "siparişiniz bize ulaştı" mesajını gösterir. Ancak stok sayısı birkaç an sonra düşer. Bu aralıkta iki sistem farklı şey söyleyebilir; yani kullanıcı kısa süre eski bilgi görebilir.

Bu bir hata değil, bilinçli bir takastır. Hatta bilinçli kurulmuş sistemlerde beklenen bir davranıştır. Microsoft belgesi, mimarların bazı akışlarda erişilebilirliği tercih ederek nihai tutarlılığı kabul ettiğini söyler. Yine de her akış buna uygun değildir.

• Arayüzde ara durum mesajları gösterin.
• Eski veriyle çalışmayı tolere edecek okuma ekranları tasarlayın.
• Anında kesin doğruluk isteyen işlemleri (örneğin bakiye kontrolü) tek bir yetkili kaynağa bırakın.

Olaylar neden iki kez gelir ve idempotency burada neden şart?

Bir tüketici olayı işledikten sonra onay gönderemezse aracı ne yapar? Birçok sistem kaybı önlemek için olayı yeniden teslim eder. Sonuç olarak aynı olay iki kez gelebilir. Kesin davranış kullandığınız aracın belgesinde yazar; bu yüzden orayı mutlaka kontrol edin.

Ancak sorun tam burada başlar. Fatura servisi aynı "ödeme geldi" olayını iki kez işlerse müşteriye iki fatura keser. Stok servisi iki kez düşerse sayım gerçeğin altında kalır.

Bu yüzden çözüm, tüketiciyi idempotent yazmaktır. İdempotent işlem, bir kez de çalışsa çok kez de çalışsa aynı sonucu bırakır. Pratik yol, olayın id değerini kaydetmek ve daha önce gördüğünüz olayı atlamaktır.

Konunun ayrıntılarını kardeş yazımızda anlattık. Idempotency nedir ve API'lerde aynı isteği iki kez işlememek için ne yaparsınız yazısını okuyarak tekrar edilen isteklere karşı pratik tasarım kalıplarını görebilirsiniz.

Olayların sırası neden şaşar ve sırayı nasıl yönetirsiniz?

Çünkü dayanıklılık için her tüketicinin birden çok kopyası çalışır. Ancak bu kopyalar olayları aynı anda ve farklı hızlarda işler. Dolayısıyla "önce A, sonra B" sırası kendiliğinden garanti olmaz.

Üstelik hata yönetimi de sırayı bozar. Microsoft belgesine göre hatalı olayı bir hata işleyiciye gönderip sonra yeniden yayınlarsanız, olay sıra dışı gelir.

Sıra önemliyse şu adımları düşünün:

• Aynı varlığa ait olayları aynı bölüme yönlendirin, çünkü bölüm içinde sıra kesindir.
• Olaya sürüm numarası ya da sıra bilgisi ekleyin; tüketici eski olayı geride kalmış sayıp atlasın.
• Öncelikle mümkünse tasarımı sıradan bağımsız hale getirin. Örneğin "durum şu" bilgisini taşıyın, yalnızca "şu değişti" demeyin.
• Sıranın gerçekten gerekli olduğu akışları ayrı tutun ve belgeleyin.

Hata ayıklama ve izlenebilirlik neden zorlaşır?

Klasik bir uygulamada hatayı çağrı zincirinde takip edersiniz. Event-driven sistemde ise tek bir iş birçok üretici, kanal ve tüketici üzerinden bağımsız geçer. Dolayısıyla ortak bir çağrı bağlamı yoktur.

Microsoft belgesi çözüm olarak her olaya bir bağlantı kimliği (correlation ID) koymayı önerir. Böylece log kayıtlarını tek bir iş olarak birleştirebilirsiniz. Üstelik bunu baştan planlamak, sonradan eklemekten çok daha ucuzdur.

• Her olayda bağlantı kimliği taşıyın ve her log satırına yazın.
• İşlenemeyen olaylar için bekleme alanı (dead-letter queue) tanımlayın; böylece olay kaybolmaz, siz inceleyebilirsiniz.
• Ayrıca tüketici başına gecikme ve hata sayısını izleyin.
• Uçtan uca test senaryolarını ayrıca planlayın, çünkü zincirleme akışlar basit testlerde ortaya çıkmaz.

AWS belgesi de akışı kod okuyarak değil, izleme yoluyla takip etmenin gerektiğini hatırlatır.

Broker mı mediator mı: iki topolojiden hangisini seçersiniz?

Microsoft belgesi iki temel topoloji tarif eder. Bu seçim, akışın karmaşıklığına ve kontrol ihtiyacına bağlıdır.

Broker topolojisinde bileşenler olayları tüm sisteme yayar. Başka bir bileşen ya işler ya yok sayar. Merkezi bir koordinasyon yoktur, bu yüzden esnektir. Ancak çok adımlı bir iş yarım kalırsa onu yeniden başlatacak yerleşik bir mekanizma yoktur.

Mediator topolojisinde bir arabulucu olay akışını yönetir. Durumu tutar, hata yönetimini ve yeniden başlatmayı da yönetir. Bu yaklaşım daha fazla kontrol sunar. Öte yandan bağlılığı artırır ve arabulucu darboğaz olabilir.

• Akış basit ve bileşenler özerkse broker topolojisiyle başlayın.
• Çok adımlı, geri alınması gereken iş akışlarında mediator düşünün.
• İkisini aynı sistemde farklı akışlar için birlikte kullanabilirsiniz.

Event-driven mimari mikroservis, serverless ve webhook ile aynı şey midir?

Hayır, aynı şey değiller; yine de bu terimler aynı konuşmalarda geçtiği için sık birbirine karışıyor. Ancak her biri farklı bir soruyu yanıtlar. Bu nedenle aşağıdaki tablo ayrımı özetliyor.

Mikroservis tarafında dil ve çatı seçimi için Python ve Go ile backend mikroservis karşılaştırmamıza bakabilirsiniz. Fonksiyonların olayla tetiklenmesi ve soğuk başlangıç sorunu için ise Serverless nedir ve cold start ne demektir yazımız yardımcı olur.

Event-driven mimariyi pratikte nerelerde görürsünüz?

Bu mimari yalnızca büyük teknoloji şirketlerine ait değildir. Örneğin küçük ve orta ölçekli işletmeler de farkında olmadan olay mantığına dayanan sistemler kullanır. Aşağıda tanıdık birkaç örnek senaryo var.

• Online mağaza: Sipariş sonrası stok, fatura, kargo ve bildirim adımları ayrı tepkiler olarak çalışır.
• Üyelik akışı: Yeni kayıt olayı hoş geldin e-postasını, müşteri kaydını ve raporlamayı birbirinden bağımsız başlatır.
• Cihaz verisi: Azure belgesi, sensör gibi cihazlardan gelen yüksek hacimli veriyi tipik bir kullanım alanı olarak gösterir.
• Entegrasyonlar: Muhasebe, CRM ve depo yazılımları aynı olayı dinleyerek birbirini elle beslemeden güncel kalır.

Ortak nokta şudur: bir şey olur ve birden çok taraf buna kendi işiyle karşılık verir. Örneğin yeni bir üye kaydında e-posta, rapor ve müşteri kartı aynı anda hareketlenir. Kayıt ekranının bunları tek tek çağırması gerekmez. Eğer akışınızda böyle bir yapı görmüyorsanız, muhtemelen daha basit bir çözüm yeterlidir.

Olay şemasını zamanla nasıl değiştirirsiniz?

Üretici ve tüketiciler ayrı zamanlarda yayına çıkar. Bu yüzden hepsini aynı anda güncelleyemezsiniz. Üretici olayın yapısını değiştirdiğinde, yeni yapıyı bilmeyen tüketici bozulabilir.

Microsoft belgesi bu nedenle şema sürümleme stratejisini erkenden belirlemeyi önerir. Ayrıca tüketicinin tanımadığı bir sürümle karşılaştığında çökmemesini ister. Yani tolerans, tasarımın parçası olmalıdır.

• Eski alanları hemen silmeyin; önce yeni alanı ekleyin ve geçiş süresi tanıyın.
• Olayda şema sürümünü açıkça taşıyın.
• Tüketicinin bilmediği alanı yok saymasını sağlayın.
• Sürüm değişikliklerini kısa bir değişiklik notuyla ekiplere duyurun.

Bu disiplin ilk bakışta sıkıcı görünebilir. Ancak olay sözleşmesi, mimarinin en uzun yaşayan parçasıdır; dolayısıyla en çok bakım isteyen parçası da odur.

Event-driven mimari ne zaman gereksizdir?

Ancak her sistem bu mimariye muhtaç değildir. Nitekim Microsoft belgesi bunu açıkça söyler. Basit istek-yanıt akışları, anında yanıt verebilen senkron çağrılarla yeterince iyi çalışıyorsa broker işletme yükü ve nihai tutarlılık gerekçelendirilemez.

• Küçük bir kurumsal site ya da tek ekipli bir uygulama için doğrudan çağrı çoğu zaman yeterlidir.
• Servisler arasında kesin ve anlık tutarlılık gerekiyorsa nihai tutarlılık sizi zorlar.
• Ekibin dağıtık ve asenkron sistem işletme deneyimi yoksa öğrenme eğrisi teslim tarihini etkiler.

Event-driven mimari nedir sorusunu "her yerde kullanalım" diye yanıtlamak yanlış olur. Dolayısıyla doğru sorunun cevabı "modaya uymak" değil, "hangi ihtiyacı çözüyoruz" olmalı. Örneğin aynı olaya birden çok bileşen tepki veriyorsa, kampanya anlarında yük dalgalanıyorsa ya da ekipler bağımsız ilerlemek istiyorsa bu mimari mantıklıdır.

Kararı birlikte değerlendirmek isterseniz özel yazılım geliştirme hizmetimize bakabilirsiniz. Çünkü mimariyi ihtiyaca göre sade tutmaya çalışıyoruz.

Başlamadan önce işletme ve geliştirici için kontrol listesi nedir?

Aşağıdaki iki liste, tasarım toplantısında konuşmanız gereken noktaları toplar. İlk olarak işletme tarafına bakalım. Bu sorulara yazılımcı değil, iş sahibi cevap vermelidir.

• Hangi süreçlerde anlık tepki gerçekten değer katıyor?
• Hangi veriler her an kesin doğru olmak zorunda?
• Bir olay ters giderse kim, hangi ekran üzerinden müdahale ediyor?
• Aracı ve izleme için kimin sorumluluğu var?

Şimdi geliştirici tarafına geçelim. Bu liste, kodlamaya başlamadan önce ekibin ortak cevabı olmalı.

• Olay adlarını geçmiş zamanla ve tek bir alan diliyle yazdınız mı?
• Her olayda benzersiz kimlik, kaynak, tür ve şema sürümü var mı?
• Tüketiciler idempotent mi, yani tekrar gelen olayı güvenle atlıyor mu?
• Bağlantı kimliği, bekleme alanı ve uyarılar hazır mı?
• Sıra gereksinimi olan akışların yazılı kuralı var mı?
• Olaylarda hassas veri yok, yalnızca referans var mı?

Küçük başlamak için hangi adımları izlersiniz?

Bütün sistemi bir anda dönüştürmeye çalışmayın. Çünkü risk büyür. Küçük, ölçülebilir bir akışla başlamak çok daha güvenlidir.

1. Tek bir iş akışı seçin. Örneğin sipariş sonrası bildirim gönderme.
2. Akışın olaylarını geçmiş zamanla adlandırın ve şemasını yazın.
3. Mevcut kodun yanına olayı yayınlayan bir adım ekleyin; eski yolu hemen kapatmayın.
4. İlk tüketiciyi idempotent olarak yazın ve bağlantı kimliğiyle izleyin.
5. Birkaç hafta gözlemleyin; hata ve gecikmeleri değerlendirin.
6. Güveniniz oluşunca eski doğrudan çağrıyı kaldırın ve bir sonraki akışa geçin.

Böylece bu yaklaşım, mimariyi ekibin öğrenme hızına uydurur. Üstelik bir şey ters giderse geri dönmek kolaydır.

Özetle event-driven mimari nedir ve kimin işine yarar?

Event-driven mimari nedir sorusunun özeti şudur: bileşenler birbirine emir vermek yerine olan biteni duyurur, ilgililer kendi işini yapar. Bu yaklaşım ayrıca gevşek bağlılık, bağımsız ölçek ve esnek büyüme sağlar.

Karşılığında nihai tutarlılık, sıra sorunu, tekrar teslim ve izleme zorluğunu yönetmeniz gerekir. Yani avantajlar bedava değildir. Ayrıca ekibin bu yeni işi üstlenecek zamanı ve bilgisi olup olmadığını da dürüstçe tartın. Kısacası önce ihtiyacı, sonra aracı seçin.

Karar verirken kaynaklara dönmenizi öneririz: Azure Architecture Center, AWS ve CloudEvents sayfaları güncel ayrıntıları taşır. Sağlayıcı özelliklerinin güncel halini her zaman resmi belgeden kontrol edin.