Backend Sistemlerinde Event-Driven (Olay Güdümlü) İletişim

Backend Sistemlerinde Event-Driven (Olay Güdümlü) İletişim, servislerin birbirini doğrudan beklemek yerine gerçekleşen olaylar üzerinden haberleşmesini sağlayan güçlü bir mimari yaklaşımdır. Özellikle mikroservis sayısı arttığında senkron HTTP çağrılarının oluşturduğu bağımlılıklar, gecikmeler ve hata zincirleri ekiplerin önüne ciddi operasyon sorunları çıkarabilir. On yıllık backend geliştirme deneyimimde, doğru tasarlanan olay güdümlü yapıların sistemleri daha bağımsız ve ölçeklenebilir hâle getirdiğini, yanlış kurulan yapıların ise hata ayıklamayı çok daha zorlaştırdığını defalarca gördüm. Bu rehberde backend sistemlerinde event-driven architecture nasıl uygulanır, mikroservislerde olay güdümlü asenkron iletişim nasıl kurulur ve production ortamında hangi kararların gerçekten önemli olduğu adım adım ele alınmaktadır. Ayrıca Kafka RabbitMQ ve Redis Streams event-driven mimari karşılaştırması gibi seçimlerde yalnızca teknoloji adına değil, veri akışına, teslim garantilerine ve operasyon ihtiyacına bakılması gerektiğini göreceksiniz.

Event-Driven Architecture (EDA) Nedir?

Event-Driven Architecture, sistem bileşenlerinin bir olay oluştuğunda bunu yayınlaması ve ilgili bileşenlerin bu olaya tepki vermesi üzerine kurulan iletişim modelidir. Producer tarafı çoğu zaman consumer tarafının kim olduğunu bilmez. Bu ayrım servisler arasında daha zayıf bir bağımlılık kurulmasına yardımcı olur. EDA yalnızca mesaj kuyruğu kullanmak anlamına gelmez, olayın anlamı, teslim davranışı, hata yönetimi ve veri tutarlılığı birlikte tasarlanmalıdır. Bu nedenle sağlam bir event-driven backend tasarımı teknolojiden önce iş akışının ve olay sözleşmesinin tanımlanmasıyla başlar.

Olay Güdümlü Mimari Nasıl Çalışır?

Bir servis önemli bir iş durumu gerçekleştiğinde olayı broker'a yayınlar. Broker bu olayı uygun queue, topic veya stream üzerinde tutar. İlgili consumer mesajı alır ve kendi sorumluluğundaki işlemi yürütür. Producer, consumer işleminin tamamlanmasını beklemek zorunda değildir. Bu yaklaşım özellikle e-posta, bildirim, raporlama, entegrasyon ve veri senkronizasyonu gibi arka plan süreçlerinde etkili sonuç verir.

Event Nedir?

Event, sistemde geçmişte gerçekleşmiş ve iş açısından anlam taşıyan bir durumu temsil eder. OrderCreated, PaymentCompleted veya UserRegistered gibi isimler event için doğal örneklerdir. Event bir talep değil, gerçekleşmiş bir gerçeğin kaydıdır. Consumer bu bilgiyi kullanarak kendi durumunu güncelleyebilir veya yeni bir işlem başlatabilir. İyi tasarlanmış bir event, domain dilini yansıtır ve teknik uygulama ayrıntılarına gereğinden fazla bağlı olmaz.

Producer Nedir?

Producer, event veya message yayınlayan uygulama bileşenidir. Producer'ın temel görevi doğru olayı doğru zamanda ve doğru contract ile üretmektir. Güvenilir sistemlerde producer tarafında dual-write riski özellikle dikkate alınır. Transactional Outbox gibi desenler burada önemli rol oynar. Producer'ın consumer davranışlarını bilmemesi bağımlılığın düşük tutulmasına yardımcı olur.

Consumer Nedir?

Consumer, broker üzerinden gelen mesajları okuyup işleyen bileşendir. Consumer'ın tekrar teslim edilen mesajlara dayanıklı olması gerekir. At-least-once kullanılan sistemlerde aynı event'in birden fazla kez alınması olağan kabul edilir. Bu nedenle idempotency, acknowledgement ve retry stratejileri consumer tasarımının temel parçalarıdır. Sağlıklı bir consumer yalnızca başarılı akışı değil, hata, yeniden başlatma ve gecikme durumlarını da yönetir.

Message Broker Nedir?

Message broker producer ile consumer arasında mesaj taşıyan altyapı bileşenidir. Broker mesajları yönlendirebilir, saklayabilir ve gerektiğinde tekrar tüketilmelerini sağlayabilir. Queue, topic, partition, acknowledgement veya retention gibi kavramlar seçilen ürüne göre değişebilir. Broker aynı zamanda ani trafik artışlarının consumer sistemlerini doğrudan çökertmesini önleyen bir tampon görevi görebilir. Ancak broker kullanmak kendi başına güvenilir event-driven mimari oluşturmaz, uygulama davranışlarının da buna uygun tasarlanması gerekir.

Event-Driven Backend'in Temel Veri Akışı

Temel akış producer'ın bir event oluşturmasıyla başlar. Event broker üzerinden uygun topic veya queue'ya gider. Consumer mesajı aldığında kendi iş kuralını çalıştırır. Ardından database güncellemesi, bildirim veya başka bir event gibi side effect oluşabilir. Production ortamında bu beş adımın tamamı gözlemlenebilir, tekrar çalıştırılabilir ve hata durumlarına dayanıklı olmalıdır.

Producer

Producer iş olayını ilk oluşturan taraftır. Event ID, timestamp ve event type gibi metadata alanlarını üretmesi beklenir. Yayınlama işlemi başarısız olduğunda davranışı açık biçimde tanımlanmalıdır. Gerekiyorsa event önce outbox tablosunda kalıcı hâle getirilir. Böylece iş verisi ile mesaj yayınlama süreci arasındaki güvenilirlik artırılır.

Broker

Broker mesajın producer'dan consumer'a güvenilir şekilde taşınmasını sağlar. Mesajları bellekte veya kalıcı depolamada tutabilir. Routing, retention ve teslim davranışı broker yapılandırmasına bağlıdır. Yüksek erişilebilirlik için replication veya quorum mekanizmaları kullanılabilir. Broker kapasitesi planlanırken mesaj hacmi, boyutu ve retention süresi birlikte değerlendirilmelidir.

Topic / Queue

Topic ve queue mesajların mantıksal olarak yerleştirildiği yapılardır. Queue çoğunlukla işi consumer'lardan birine dağıtmak için kullanılır. Topic ise aynı olayın birden fazla bağımsız consumer grubuna aktarılmasını kolaylaştırır. Tasarım sırasında isimlendirme, ownership ve retention politikaları belirlenmelidir. Gereğinden fazla topic oluşturmak kadar her şeyi tek topic altında toplamak da sorun yaratabilir.

Consumer

Consumer mesajı alır ve ilgili iş davranışını gerçekleştirir. Mesaj başarıyla işlendiğinde ack veya offset yönetimi yapılır. İşlem başarısız olduğunda retry ya da DLQ devreye girebilir. Consumer duplicate event alabileceğini varsaymalıdır. Aynı zamanda graceful shutdown sırasında devam eden mesajların güvenli biçimde tamamlanması gerekir.

Side Effect

Side effect, event işleme sonucunda dış dünyada oluşan değişikliktir. Database kaydı, e-posta gönderimi veya ödeme çağrısı buna örnektir. Side effect tekrar çalıştırıldığında istenmeyen sonuç üretme riski vardır. Bu nedenle idempotency ve deduplication mekanizmaları özellikle önemlidir. Replay senaryolarında hangi side effect'lerin tekrar edilip edilmeyeceği önceden belirlenmelidir.

Event-Driven İletişim Neden Kullanılır?

Event-driven iletişimin temel amacı yalnızca işlemleri asenkron hâle getirmek değildir. Asıl değer servislerin birbirinden daha bağımsız çalışabilmesidir. Trafik artışlarında broker tampon görevi üstlenebilir ve consumer kapasitesi ayrı ölçeklenebilir. Bir consumer geçici olarak çalışmasa bile producer bazı mimarilerde işine devam edebilir. Bu özellikler olay güdümlü iletişimi mikroservis, entegrasyon, bildirim, analitik ve yüksek hacimli backend sistemlerinde güçlü bir seçenek hâline getirir.

Servisler Arasında Loose Coupling

Loose coupling, servislerin birbirinin iç yapısına daha az bağımlı olması anlamına gelir. Producer çoğu zaman yalnızca event contract'ını bilir. Consumer sayısının artması producer kodunu değiştirmeyi gerektirmeyebilir. Böylece ekipler farklı hızlarda geliştirme ve dağıtım yapabilir. Ancak schema yönetimi zayıf bırakılırsa bu avantaj zamanla tersine dönebilir.

Asenkron İşleme

Asenkron işleme, producer'ın consumer sonucunu beklemeden ilerlemesini sağlar. Kullanıcı isteğinin parçası olması gerekmeyen işler bu şekilde arka plana alınabilir. Örneğin sipariş oluşturulduktan sonra e-posta gönderimi ayrı bir consumer tarafından yapılabilir. Kullanıcı daha hızlı yanıt alırken ağır süreçler bağımsız yürütülür. Bunun karşılığında durum takibi ve hata yönetimi daha disiplinli tasarlanmalıdır.

Ölçeklenebilirlik

Event-driven sistemlerde producer ve consumer kapasitesi bağımsız ölçeklenebilir. Tüketim yavaşladığında yeni consumer instance'ları eklenebilir. Kafka gibi yapılarda partition sayısı paralellik üst sınırını etkiler. RabbitMQ tarafında competing consumer modeli iş yükünü farklı instance'lara dağıtabilir. Ölçek kararı yalnızca CPU kullanımına değil, lag, queue depth ve işleme süresine de dayanmalıdır.

Failure Isolation

Failure isolation, bir servisteki hatanın diğer servislere doğrudan yayılmasını azaltmayı amaçlar. Senkron zincirde bir servis çöktüğünde üst servislerin timeout yaşaması mümkündür. Event-driven akışta broker bazı durumlarda mesajları saklamaya devam eder. Consumer tekrar ayağa kalktığında geride kalan mesajları işleyebilir. Bunun için retention, retry ve kapasite ayarlarının gerçek trafikle uyumlu olması gerekir.

Gerçek Zamanlı Veri Akışı

Event stream'leri iş olaylarının düşük gecikmeyle farklı sistemlere taşınmasını sağlar. Analitik, fraud kontrolü, bildirim ve arama indeksleme gibi süreçler bundan yararlanabilir. Buradaki gerçek zaman kavramı sıfır gecikme anlamına gelmez. Uçtan uca gecikme broker, network ve consumer işleme süresine bağlıdır. Bu yüzden p95 ve p99 event latency metriklerinin izlenmesi pratikte değerlidir.

Yeni Consumer'ların Producer'ı Değiştirmeden Eklenebilmesi

İyi tasarlanmış pub/sub modelinde yeni consumer mevcut producer'a dokunmadan sisteme eklenebilir. Örneğin OrderCreated event'ini bildirim servisi ve analitik servisi ayrı ayrı tüketebilir. Producer bu consumer'ların varlığından haberdar olmak zorunda değildir. Bu yaklaşım yeni özelliklerin mevcut iş akışına daha az müdahaleyle eklenmesini sağlar. Yine de event contract değişiklikleri tüm consumer'ları etkileyebileceği için governance önemini korur.

Event-Driven Architecture'ın Dezavantajları

Event-driven architecture güçlü avantajlar sunarken yeni operasyon sorumlulukları da getirir. Dağıtık akışlarda hatanın hangi adımda oluştuğunu bulmak senkron uygulamalara göre daha zor olabilir. Veri çoğu zaman servisler arasında aynı anda güncel değildir. Duplicate delivery, ordering ve schema evolution gibi konular doğrudan tasarım problemi hâline gelir. Bu yüzden EDA yalnızca moda olduğu için değil, ihtiyaç net biçimde ortaya çıktığında tercih edilmelidir.

Eventual Consistency

Eventual consistency, farklı servislerdeki verilerin kısa süre boyunca farklı durumda olabilmesidir. Bir sipariş oluşturulduktan hemen sonra raporlama servisi yeni kaydı henüz görmeyebilir. Bu davranış iş gereksinimleri açısından kabul edilebilir veya edilemez olabilir. Kullanıcı arayüzü ve business flow bu gecikmeyi hesaba katmalıdır. Kritik alanlarda reconciliation süreçleri de planlanmalıdır.

Debugging Karmaşıklığı

Asenkron akışlarda tek bir isteğin birden fazla event ve consumer üzerinden ilerlemesi mümkündür. Hatanın kaynağını yalnızca uygulama loglarına bakarak bulmak güçleşebilir. Correlation ID, causation ID ve distributed tracing burada önemli hâle gelir. Her mesajın topic, partition, offset ve processing result bilgisi kaydedilebilir. İyi observability olmadan production sorunlarının çözüm süresi ciddi biçimde uzayabilir.

Duplicate Message

Bir mesaj broker veya consumer davranışı nedeniyle tekrar teslim edilebilir. Özellikle at-least-once yaklaşımında bu durum beklenen davranıştır. Consumer duplicate mesajı yeni bir işlem gibi ele almamalıdır. Event ID ve unique constraint kullanılarak daha önce işlenen kayıtlar tespit edilebilir. İşlem ile deduplication kaydının aynı transaction içinde yapılması güvenilirliği artırır.

Event Ordering

Dağıtık sistemlerde tüm mesajlar için global ordering sağlamak pahalıdır. Çoğu iş senaryosunda aggregate bazında sıra yeterlidir. Kafka'da aynı key değerine sahip event'ler aynı partition'a yönlendirilerek sıra korunabilir. Paralellik arttıkça ordering garantisi ile throughput arasında denge kurulması gerekir. Gerçek ihtiyacı tanımlamadan global sıra beklemek ölçeklenebilirliği gereksiz yere sınırlar.

Schema Evolution

Event contract zaman içinde değişmek zorundadır. Yeni alan eklemek çoğu zaman eski consumer'ları bozmadan yapılabilir. Ancak required field eklemek veya field type değiştirmek daha risklidir. Schema Registry ve compatibility kontrolleri bu değişikliklerin güvenli yönetilmesine yardımcı olur. Event'ler uzun ömürlü API sözleşmeleri gibi ele alınmalıdır.

Operasyonel Broker Maliyeti

Message broker kullanmak yeni altyapı sorumlulukları getirir. Broker kapasitesi, disk kullanımı, replication, güvenlik ve upgrade süreçleri takip edilmelidir. Managed hizmetler bazı operasyon yüklerini azaltabilir. Buna rağmen topic tasarımı, consumer lag ve hata yönetimi uygulama ekibinin sorumluluğunda kalır. Broker seçimi yapılırken yalnızca performans değil, işletme kabiliyeti de değerlendirilmelidir.

Distributed Transaction Problemi

Bir business operation birden fazla servis ve database içerdiğinde klasik ACID transaction yaklaşımı doğrudan uygulanamaz. İki sisteme aynı anda atomik yazmak zordur. Saga, Outbox ve idempotent consumer gibi desenler bu noktada devreye girer. Amaç tüm dünyayı tek transaction içinde tutmak değil, başarısızlıkları yönetilebilir hâle getirmektir. Eventual consistency kabul edilmeden gerçek anlamda dağıtık tasarım yapmak genellikle mümkün olmaz.

Senkron ve Asenkron İletişim Arasındaki Fark

Senkron iletişimde çağrıyı yapan taraf genellikle karşı servisten yanıt bekler. Asenkron iletişimde producer işi yayınlar ve consumer daha sonra işleyebilir. REST ve gRPC çoğunlukla request-response modeliyle kullanılırken queue ve pub/sub çözümleri asenkron iletişimi destekler. İki yaklaşımın biri diğerinden mutlak olarak daha iyi değildir. Production sistemlerinde çoğu zaman senkron ve asenkron yöntemlerin birlikte kullanıldığı hibrit tasarım en mantıklı sonucu verir.

REST / HTTP

REST üzerinden HTTP iletişimi okunabilir ve yaygın bir request-response modelidir. Kullanıcı anında sonuç beklediğinde doğal bir seçimdir. Ancak servis zinciri uzadıkça timeout ve cascading failure riski büyür. Retry yanlış kullanılırsa aynı business operation birden fazla kez çalışabilir. Bu nedenle senkron API'lerde de idempotency ve timeout politikaları önemlidir.

gRPC

gRPC düşük gecikme ve güçlü contract ihtiyacında sık kullanılan bir RPC yaklaşımıdır. Protocol Buffers sayesinde mesaj yapıları açık biçimde tanımlanır. Servisler arası iç iletişimde performans avantajı sağlayabilir. Buna karşın çağıran servis yine karşı servisin erişilebilirliğine bağlıdır. Bu nedenle gRPC kullanmak dağıtık sistemlerde bağımlılık sorununu tek başına çözmez.

Message Queue

Message queue işleri producer'dan ayırıp consumer'lara dağıtmak için kullanılır. Bir mesajın çoğu zaman tek consumer tarafından işlenmesi hedeflenir. Worker queue, e-posta gönderimi ve background processing bunun yaygın örnekleridir. Queue geçici trafik artışlarını tamponlayabilir. Ancak queue büyümesi sürekli oluyorsa sorun kapasite veya downstream performansında olabilir.

Publish/Subscribe

Publish/Subscribe modelinde bir event birden fazla bağımsız subscriber tarafından tüketilebilir. Producer hangi subscriber'ların bulunduğunu bilmez. Yeni bir consumer eklemek mevcut producer kodunu değiştirmeyi gerektirmeyebilir. Bu yapı entegrasyon ve event notification senaryolarında güçlüdür. Event schema yönetimi ise subscriber sayısı büyüdükçe daha önemli hâle gelir.

Request–Response

Request–Response modelinde çağıran taraf karşı taraftan belirli bir cevap bekler. Kullanıcıya hemen sonuç göstermek gereken işlemler için uygundur. Ödeme yetkilendirme sonucu veya oturum açma kontrolü buna örnek olabilir. Bu modelde timeout, circuit breaker ve retry politikalarının sınırları açık olmalıdır. Zincir hâlindeki çağrıların sayısı arttıkça toplam gecikme de artar.

Fire-and-Forget

Fire-and-forget yaklaşımında producer mesajı gönderir ve sonucu takip etmez. Kritik olmayan telemetri veya düşük riskli bildirimlerde kullanılabilir. Ancak mesajın gerçekten işlendiğine dair garanti sınırlı olabilir. Kritik business event'lerde bu yaklaşım çoğu zaman yetersiz kalır. Teslim ve işlem sonucunun önemli olduğu yerlerde acknowledgement ve retry mekanizmaları gerekir.

Hangi Senaryoda Hangisi Tercih Edilmeli?

Kullanıcı sonucu hemen bekliyorsa senkron iletişim daha doğal olabilir. Uzun süren veya bağımsız arka plan işleri için asenkron model daha uygundur. Birden fazla servis aynı olayı tüketiyorsa pub/sub güçlü bir seçenektir. Tek işin worker havuzuna dağıtılması gerekiyorsa queue modeli daha sade olabilir. Karar verirken latency, consistency, failure tolerance ve operasyon maliyetini birlikte değerlendirmek gerekir.

Bir Sistem Tamamen Asenkron Olmalı mı?

Bir sistemin tamamen asenkron olması çoğu ürün için gerekli değildir. Kullanıcının anında doğrulama beklediği işlemlerde senkron yanıt daha anlaşılır bir deneyim sağlar. Arka planda yürütülebilen görevler event veya queue ile ayrıştırılabilir. Benim tercih ettiğim yaklaşım çoğu zaman HTTP command ile başlayan ve sonrasında event yayınlayan hibrit modeldir. Böylece kullanıcıya gerekli sonuç hızlı verilirken sonraki işler servisler arasında bağımsız ilerleyebilir.

Kullanıcının Anında Sonuç Beklediği İşlemler

Kullanıcı giriş yaptığında kimlik doğrulama sonucunu hemen görmek ister. Benzer biçimde ödeme başlatma veya kritik form doğrulaması anlık geri bildirim gerektirebilir. Bu işlemleri tamamen asenkron yapmak kullanıcı deneyimini gereksiz biçimde zorlaştırabilir. Senkron endpoint işin gerekli bölümünü tamamlayabilir. Ardından ikincil işlemler event üzerinden yürütülebilir.

Asenkron Background İşlemler

E-posta gönderimi, rapor üretimi ve arama indeksleme gibi işler çoğu zaman background sürece uygundur. Kullanıcının bu görevlerin tamamlanmasını beklemesi gerekmez. İş event olarak yayınlanıp worker tarafından daha sonra tamamlanabilir. Failure durumunda retry ve DLQ devreye girebilir. Bu tasarım kullanıcı isteğinin response süresini de azaltabilir.

Hybrid Communication

Hybrid communication senkron ve asenkron yaklaşımları aynı business flow içinde kullanır. İlk command HTTP üzerinden alınabilir. Transaction tamamlandıktan sonra event yayınlanabilir. İlgili consumer'lar sonraki adımları bağımsız yürütür. Bu yapı birçok kurumsal backend sistemi için dengeli bir mimari sunar.

HTTP Command + Async Event Yaklaşımı

HTTP command ile kullanıcı isteği doğrulanır ve ana business state güncellenir. Aynı transaction içinde Outbox kaydı oluşturulabilir. Commit sonrasında event broker'a aktarılır. Consumer'lar bildirim, entegrasyon veya analitik süreçlerini başlatır. Bu yöntem hem kullanıcı deneyimini hem de producer güvenilirliğini birlikte ele alır.

Event, Command ve Message Arasındaki Fark

Event, command ve message kavramlarının birbirinden ayrılması event-driven tasarımın temelidir. Event gerçekleşmiş bir olayı anlatır. Command yapılması istenen işi temsil eder. Message ise transport seviyesinde event veya command taşıyabilen daha genel bir kavramdır. Bu ayrım isimlendirmede korunmadığında sistem davranışını anlamak ve ownership belirlemek zorlaşır.

Event

Event geçmişte gerçekleşmiş iş gerçeğini ifade eder. Producer event'i yayınlarken consumer'dan belirli bir davranışı emretmez. Birden fazla consumer aynı event'e farklı şekillerde tepki verebilir. Event isimleri genellikle geçmiş zamanlı olur. OrderCreated ve InvoiceIssued buna iyi örneklerdir.

Gerçekleşmiş Bir Olay

Event'in temel özelliği gerçekleşmiş bir durumu temsil etmesidir. Bu durum sonradan geri alınsa bile event geçmişte olmuş gerçeği ifade eder. Consumer event'i bir bildirim olarak okuyabilir. Olayın anlamı business language ile açık olmalıdır. Teknik metot adı kullanmak event'in amacını bulanıklaştırabilir.

Geçmiş Zamanlı İsim

Geçmiş zamanlı isim event'in gerçekleşmiş bir olayı anlattığını belli eder. PaymentCompleted bunun açık bir örneğidir. CompletePayment ise daha çok command anlamı taşır. İsimlendirme yalnızca estetik değildir. Yanlış isim consumer'ın mesajı nasıl yorumlaması gerektiğini belirsizleştirebilir.

Command

Command bir işin yapılmasını isteyen mesajdır. Çoğu zaman hedeflenen bir handler veya servis vardır. Başarısız olabilir ve sonucu önemlidir. Command isimleri eylem odaklı seçilir. CreateOrder veya ReserveInventory buna örnek verilebilir.

Yapılması İstenen Bir İş

Command gerçekleşmiş bir gerçeği değil niyeti temsil eder. İş henüz tamamlanmamış olabilir. Handler command'i doğrular ve başarı veya hata sonucu üretir. Bu ayrım iş akışlarının daha kolay okunmasını sağlar. Command ile event aynı contract gibi kullanılmamalıdır.

Emir Kipinde İsim

Command isimleri yapılması istenen davranışı açıkça ifade etmelidir. SendEmail veya CapturePayment gibi isimler buna uygundur. İsim consumer'ın sorumluluğunu netleştirir. Command'in event gibi geçmiş zamanlı adlandırılması yanlış beklenti oluşturabilir. İyi naming convention ekipler arası iletişimi de kolaylaştırır.

Message

Message transport seviyesinde kullanılan daha genel bir kavramdır. Bir message event, command veya notification taşıyabilir. Broker çoğu zaman business anlamını bilmez. Routing ve delivery metadata üzerinden yürütülebilir. Bu yüzden message ile domain event kavramlarını birebir aynı saymamak gerekir.

Transport Seviyesi Kapsayıcı Kavram

Message broker açısından taşınan veri bir mesajdır. Uygulama açısından bu mesajın iş anlamı event veya command olabilir. Bu ayrım mimari dilin daha açık olmasını sağlar. Transport yapısı değişse bile domain anlamı korunabilir. Böylece uygulama tasarımı belirli broker terminolojisine gereğinden fazla bağlanmaz.

Command'i Event Gibi İsimlendirmenin Riski

Bir command geçmiş zamanlı event adıyla yayınlandığında semantik bulanıklaşır. Consumer bunun gerçekleşmiş bir gerçek mi yoksa yapılması beklenen iş mi olduğunu anlayamayabilir. Retry durumunda daha ciddi business sorunları oluşabilir. Ownership ve hata sorumluluğu belirsiz hâle gelir. Bu nedenle contract isimleri sistem davranışının gerçek anlamını yansıtmalıdır.

Domain Event ve Integration Event

Domain Event ile Integration Event aynı olaydan doğabilse de farklı sınırlar için tasarlanır. Domain Event belirli bounded context içindeki modeli ifade eder. Integration Event ise servisler veya domain sınırları arasında paylaşılmak üzere daha kararlı bir contract sunar. İç domain nesnesini doğrudan dışarıya açmak uzun vadede coupling yaratır. Bu ayrım büyük mikroservis sistemlerinde schema değişikliklerini daha kontrollü yönetmeye yardımcı olur.

Domain Event Nedir?

Domain Event bounded context içinde gerçekleşmiş önemli bir olayı temsil eder. Domain modeliyle yakın ilişkilidir. Aggregate davranışı sırasında üretilebilir. İç uygulama ayrıntıları taşıması bazı durumlarda sorun olmayabilir. Ancak dış servislerle paylaşılacaksa ayrı integration contract üretmek daha güvenlidir.

Integration Event Nedir?

Integration Event servisler arası iletişim için tasarlanan contract'tır. Dış consumer'ların uzun süre güvenebileceği alanlar içermelidir. Internal class yapısına birebir bağlı olmaması gerekir. Versioning ve compatibility politikaları bu event'lerde özellikle önemlidir. Event owner değişikliklerin consumer etkisini takip etmelidir.

Domain İçindeki Event'ler

Domain içindeki event'ler uygulama sınırı dışına çıkmadan davranışları ayırabilir. Aynı process içinde handler tarafından tüketilebilirler. Bu event'ler dış integration contract'ı kadar kararlı olmak zorunda değildir. Yine de isimleri business anlamını doğru yansıtmalıdır. Domain tasarımı değiştiğinde bu event'ler daha rahat evrilebilir.

Servisler Arası Event'ler

Servisler arası event'ler daha güçlü governance gerektirir. Consumer'ların farklı ekipler tarafından geliştirildiği düşünülmelidir. Field silme veya type değiştirme gibi kararlar dış etkiler yaratabilir. Schema Registry ve compatibility gate burada değerlidir. Bu event'lerin dokümantasyonu event catalog içinde tutulabilir.

İç Domain Modelini Dışarıya Sızdırmamak

Internal DTO veya entity yapısını doğrudan event payload olarak kullanmak güçlü coupling oluşturur. Domain içindeki küçük refactor bile dış consumer'ları etkileyebilir. Bunun yerine integration event için ayrı contract tanımlanmalıdır. Mapping maliyeti ilk başta ek iş gibi görünür. Uzun vadede servislerin bağımsız gelişebilmesi açısından bu maliyet çoğu zaman değerlidir.

Event Türleri

Event'ler taşınan bilgi miktarı ve kullanım amacına göre farklı biçimlerde tasarlanabilir. Notification Event yalnızca bir şeyin gerçekleştiğini haber verebilir. Event-Carried State Transfer gerekli state'i consumer'a birlikte taşıyabilir. Delta Event yalnızca değişen alanlara odaklanabilir. Doğru event türü seçimi network maliyeti, coupling, replay ve incident recovery davranışlarını doğrudan etkiler.

Notification Event

Notification Event consumer'a bir değişiklik olduğunu bildirir. Payload çoğu zaman küçük tutulur. Consumer ayrıntılı bilgiye ihtiyaç duyarsa ek API çağrısı yapabilir. Bu yaklaşım event boyutunu azaltır. Ancak producer servisine runtime bağımlılık yaratma riski vardır.

Thin Event

Thin Event az miktarda veri taşır. Genellikle event ID, entity ID ve event type yeterli olabilir. Küçük payload network kullanımını azaltır. Consumer detay için başka kaynağa başvurabilir. Bu durum event replay sırasında ek bağımlılıklar oluşturabilir.

Consumer'ın Ek Veri Çekmesi

Consumer thin event aldığında güncel state'i API veya database üzerinden çekebilir. Bu yöntem event'i sade tutar. Fakat producer servis geçici olarak erişilemezse işleme gecikebilir. Ayrıca event zamanı ile sorgu zamanı arasındaki state farklı olabilir. Bu nedenle temporal consistency gereksinimi iyi değerlendirilmelidir.

Event-Carried State Transfer

Event-Carried State Transfer consumer'ın ihtiyaç duyduğu veriyi event içinde taşır. Consumer ek API çağrısı yapmadan işlem yapabilir. Bu yaklaşım servisler arası runtime coupling'i azaltır. Payload büyüklüğü ve schema değişim maliyeti artabilir. Veri minimizasyonu da özellikle kişisel bilgiler için önem kazanır.

Fat Event

Fat Event daha geniş state bilgisi taşır. Consumer'ın kendi kendine yetmesini kolaylaştırır. Incident recovery ve replay senaryolarında avantaj sağlayabilir. Ancak büyük payload broker storage ve network maliyetini yükseltir. Gereksiz field taşımaktan kaçınmak gerekir.

Consumer'ın Kendi Kendine Yetmesi

Kendi kendine yeten consumer dış API çağrısını azaltır. Bu durum availability bağımlılığını düşürebilir. Event içinde ihtiyaç duyulan snapshot bilgisi bulunur. Consumer replay sırasında geçmiş event'i kendi başına değerlendirebilir. Buna karşılık schema contract daha dikkatli yönetilmelidir.

Delta Event

Delta Event yalnızca değişmiş alanları taşır. Büyük entity'lerde payload miktarını azaltabilir. Consumer'ın önceki state'i doğru biliyor olması gerekir. Event kaçırıldığında state bozulma riski oluşabilir. Bu model seçilirken replay ve reconciliation stratejisi tanımlanmalıdır.

Yalnızca Değişen Alanlar

Yalnızca değişen alanları göndermek network kullanımını azaltabilir. Örneğin profile update event'i tüm kullanıcıyı değil değişen alanı taşıyabilir. Consumer mevcut state ile delta'yı birleştirir. Event sırası bu yaklaşımda daha kritik hâle gelir. Out-of-order delivery yanlış state üretebilir.

Domain Event

Domain Event iş modelindeki anlamlı değişimi temsil eder. Genellikle aggregate davranışından doğar. İç domain kurallarına yakın olabilir. Integration sınırının dışında kalması mümkündür. Dış sistemlere aktarılırken uygun integration event'e dönüştürülebilir.

Integration Event

Integration Event servis sınırları arasında paylaşılır. Contract kararlılığı yüksek önem taşır. Event owner ve schema version bilgisi tanımlanmalıdır. Consumer ekipleri breaking change'lerden korunmalıdır. Bu event'ler kurum çapında event catalog içinde görünür hâle getirilebilir.

Tombstone Event

Tombstone Event bir kaydın silindiğini veya artık geçerli olmadığını belirtir. Kafka log compaction senaryolarında özel anlam taşıyabilir. Consumer kendi local state'inden ilgili kaydı kaldırabilir. Silme taleplerinin downstream sistemlere yayılmasında da kullanılabilir. Kişisel veri süreçlerinde retention ve silme davranışı dikkatle tasarlanmalıdır.

Thin Event mi Fat Event mi?

Thin ve fat event seçimi her sistem için aynı değildir. Thin event küçük payload sunarken consumer'ı ek veri kaynağına bağımlı hâle getirebilir. Fat event consumer'ı bağımsızlaştırırken network ve schema maliyetini artırır. Ben production sistemlerinde karar verirken replay ihtiyacı, veri hassasiyeti ve consumer özerkliğine birlikte bakıyorum. En iyi sonuç genellikle consumer'ın gerçekten ihtiyaç duyduğu veriyi taşıyan dengeli bir integration event tasarımıyla elde edilir.

Payload Boyutu

Payload büyüdükçe broker storage ve network maliyeti artar. Küçük mesajlar yüksek throughput için daha avantajlı olabilir. Ancak aşırı küçük event'ler ek API trafiği doğurabilir. Mesaj boyutu kapasite testlerinde ölçülmelidir. Broker limitleri de production öncesinde doğrulanmalıdır.

Network Kullanımı

Fat event'ler daha fazla network bandwidth tüketir. Consumer sayısı arttığında aynı payload birden fazla kez taşınabilir. Compression bu maliyeti azaltabilir. Buna rağmen gereksiz veri göndermek iyi bir çözüm değildir. Özellikle büyük listeler veya binary içerikler event içine konulmamalıdır.

Consumer Coupling

Thin event consumer'ı producer API'sine bağlayabilir. Fat event runtime bağımlılığını azaltabilir. Fakat geniş schema consumer'ı contract alanlarına daha fazla bağlayabilir. Coupling yalnızca HTTP çağrısı olarak düşünülmemelidir. Veri contract'ı da güçlü bir bağımlılık oluşturabilir.

Ek API Çağrıları

Thin event consumer'ın ek API çağrısı yapmasını gerektirebilir. Bu çağrılar latency ve failure riskini artırır. Producer servis unavailable olduğunda consumer mesajı işleyemeyebilir. Retry sayısı ve queue lag büyüyebilir. Bu nedenle ek çağrı gereksinimi yoğun trafikte özellikle ölçülmelidir.

Incident Recovery

Fat event geçmiş state'i daha iyi koruduğu için recovery sırasında avantaj sağlayabilir. Thin event replay edildiğinde güncel API state'i geçmiş olayla uyuşmayabilir. Bu durum yeniden işleme sonucunu değiştirebilir. Audit gerektiren sistemlerde geçmiş bilgi önemlidir. Event tasarımında recovery senaryosu baştan düşünülmelidir.

Schema Değişim Maliyeti

Payload büyüdükçe schema'daki alan sayısı artar. Daha fazla alan daha fazla compatibility kararı anlamına gelir. Consumer'ların hangi alanları kullandığı bilinmeden silme yapmak risklidir. Event catalog bu bağımlılıkları görünür kılabilir. Schema Registry ise teknik uyumluluk kontrolünü otomatikleştirebilir.

Hangi Senaryoda Hangisi?

Consumer bağımsızlığı önemliyse gerekli state'i event ile taşımak faydalıdır. Veri çok büyükse thin event veya object storage reference düşünülebilir. Hassas veri söz konusuysa mümkün olan en az veri taşınmalıdır. Replay sırasında geçmiş state önemliyse event-carried state transfer güçlü bir seçenektir. Karar verirken yalnızca mesaj boyutuna değil tüm sistem davranışına bakılmalıdır.

Point-to-Point Queue Nedir?

Point-to-Point Queue modelinde bir mesaj genellikle consumer'lardan yalnızca biri tarafından işlenir. Aynı queue'yu dinleyen birden fazla worker olabilir. Broker mesajları bu worker'lar arasında dağıtır. Bu model background job ve iş kuyruğu senaryolarında yaygındır. RabbitMQ gibi sistemlerde competing consumer tasarımıyla yatay ölçekleme yapılabilir.

Tek Mesajı Bir Consumer'ın İşlemesi

Queue semantiğinde amaç bir işi tek worker'ın tamamlamasıdır. Mesaj aynı anda tüm consumer'lara gönderilmez. Consumer başarısız olursa mesaj yeniden kuyruğa alınabilir. Acknowledgement bu davranışı kontrol eder. Duplicate ihtimali yine tamamen ortadan kalkmaz.

Competing Consumers

Competing Consumers aynı queue üzerinden mesaj almak için yarışan worker'lardır. Broker işi uygun consumer'a dağıtır. Yeni consumer eklemek processing kapasitesini artırabilir. Prefetch ayarı dağılım davranışını etkiler. Yavaş consumer'ların sistemi kilitlememesi için metrikler izlenmelidir.

Work Queue

Work Queue uzun süren işleri web request akışından ayırır. Rapor üretimi veya dosya işleme buna örnektir. Producer görevi kuyruğa yazar. Worker uygun olduğunda mesajı alır. Hata durumunda retry veya DLQ ile kontrollü davranış sağlanır.

Load Distribution

Queue iş yükünü birden fazla consumer instance'a dağıtabilir. Bu yapı yatay ölçekleme sağlar. Mesajların işleme süreleri farklıysa dağılım eşit olmayabilir. Prefetch ve concurrency ayarları test edilmelidir. Yalnızca instance sayısını artırmak downstream limitleri aşmaya neden olabilir.

Publish/Subscribe Nedir?

Publish/Subscribe modelinde producer bir event yayınlar ve birden fazla subscriber bu event'i bağımsız olarak tüketebilir. Her subscriber kendi iş amacına göre event'e tepki verir. Producer subscriber listesini bilmek zorunda değildir. Bu yapı servislerin yeni ihtiyaçlara daha esnek biçimde bağlanmasını sağlar. Özellikle mikroservislerde olay güdümlü asenkron iletişim nasıl kurulur sorusunun önemli cevaplarından biri doğru tasarlanmış topic ve subscription modelidir.

Bir Event'in Birden Fazla Consumer'a Gitmesi

Tek bir business event birden fazla sistem için anlam taşıyabilir. OrderCreated event'i faturalama, bildirim ve analitik servisleri tarafından tüketilebilir. Her consumer farklı sonuç üretir. Consumer'lardan birinin hata vermesi diğerlerinin işini doğrudan durdurmamalıdır. Bu ayrım pub/sub modelinin temel değerlerinden biridir.

Topic

Topic event'lerin mantıksal olarak yayınlandığı kanaldır. Producer topic'e mesaj gönderir. Farklı consumer group'lar aynı mesajı bağımsız okuyabilir. Topic naming convention domain anlamını yansıtmalıdır. Retention ve partition ayarları kullanım senaryosuna göre belirlenmelidir.

Subscription

Subscription belirli event akışını tüketen bağımsız aboneliği temsil eder. Cloud messaging sistemlerinde her subscription farklı teslim durumuna sahip olabilir. Bir subscriber geride kaldığında diğer subscriber'ların ilerlemesini engellemeyebilir. Retry ve DLQ politikaları subscription seviyesinde uygulanabilir. Bu yapı consumer sorumluluklarını birbirinden ayırır.

Fan-Out

Fan-Out tek mesajın birden fazla hedefe dağıtılmasını ifade eder. Bildirim sistemleri buna iyi örnektir. Bir event farklı queue veya subscriber'lara yönlendirilebilir. Consumer'lar birbirinden bağımsız çalışabilir. Routing modelinin doğru seçilmesi gereksiz mesaj trafiğini azaltır.

Producer'ın Consumer'ları Bilmemesi

Producer yalnızca event contract ve yayın hedefini bilmelidir. Hangi consumer'ın event'i işleyeceğini bilmemesi loose coupling sağlar. Yeni consumer eklemek producer deployment'ı gerektirmeyebilir. Buna rağmen event owner consumer etkilerini takip etmelidir. Tam bağımsızlık değil, iyi yönetilen contract bağımlılığı hedeflenmelidir.

Queue ve Topic Arasındaki Fark

Queue ve topic ilk bakışta benzer görünse de iletişim semantiği farklıdır. Queue çoğunlukla bir işin consumer'lardan biri tarafından tamamlanmasını sağlar. Topic aynı event'i farklı consumer gruplarına sunar. Kafka tarafında retention ve replay doğal özelliklerken klasik queue sistemlerinde mesaj çoğu zaman ack sonrasında kaldırılır. Seçim işin bir worker'a dağıtılması mı yoksa event'in birden fazla bağımsız servise yayılması mı gerektiğine göre yapılmalıdır.

Queue Semantiği

Queue içindeki mesaj bir worker tarafından alınır ve işlenir. Başarı sonrası mesaj kaldırılabilir. Aynı queue'yu birden fazla consumer paylaşabilir. Broker işi consumer'lar arasında dağıtır. Bu model görev dağıtımı için doğaldır.

Topic Semantiği

Topic yayınlanan event akışını temsil eder. Farklı consumer group'lar event'i bağımsız tüketebilir. Mesajlar retention süresi boyunca saklanabilir. Consumer kendi ilerleme bilgisini tutabilir. Bu yapı replay ihtiyacında avantaj sağlar.

Consumer Grupları

Consumer group aynı logical consumer'ın birden fazla instance'ını temsil eder. Kafka'da partition'lar group üyeleri arasında dağıtılır. Aynı group içindeki iki consumer aynı partition'ı eşzamanlı tüketmez. Farklı group'lar ise aynı event'i ayrı ayrı okuyabilir. Group tasarımı processing paralelliğini belirler.

Event Retention

Retention event'in broker üzerinde ne kadar süre tutulacağını belirler. Kafka mesajları tüketildikten sonra da saklayabilir. Bu durum replay ve backfill işlemlerini kolaylaştırır. Uzun retention storage maliyetini artırır. Veri sınıflandırması ve kişisel veri gereksinimleri de retention kararına dahil edilmelidir.

Replay

Replay geçmiş event'lerin yeniden tüketilmesidir. Yeni consumer oluştururken geçmiş veriyi işlemek için kullanılabilir. Projection yeniden inşa etmek de yaygın bir kullanım alanıdır. Side effect üreten consumer'larda replay tehlikeli olabilir. Replay-safe tasarım olmadan geçmiş mesajları kör biçimde yeniden çalıştırmamak gerekir.

Message Broker Neden Gereklidir?

Message broker producer ve consumer arasındaki doğrudan bağımlılığı azaltır. Mesajları tamponlayarak kısa süreli yük farklarını absorbe edebilir. Persistence sayesinde consumer kapalıyken mesajların korunması mümkün olabilir. Routing ve retry mekanizmaları farklı mesaj akışlarının yönetilmesini kolaylaştırır. Broker aynı zamanda backpressure yönetiminin merkezinde yer alır, ancak kapasite ve retention sınırlarının doğru ayarlanması gerekir.

Producer ve Consumer'ı Ayırmak

Broker producer ile consumer arasında aracı olur. Producer consumer endpoint'ini doğrudan çağırmak zorunda değildir. Consumer geçici olarak unavailable olabilir. Mesaj broker üzerinde bekleyebilir. Bu ayrım servislerin deployment bağımsızlığını artırabilir.

Buffer Oluşturmak

Broker ani trafik artışlarında buffer görevi görebilir. Producer kısa süreli olarak consumer'dan hızlı çalışabilir. Mesajlar queue veya log üzerinde birikir. Consumer kapasitesi yeterliyse backlog zamanla kapanır. Sürekli büyüyen backlog ise kapasite sorununun işaretidir.

Retry

Broker veya consumer framework başarısız mesajları tekrar teslim edebilir. Retry geçici hatalarda faydalıdır. Her hata için retry yapmak doğru değildir. Backoff ve jitter sistem yükünü korumaya yardımcı olur. Maksimum deneme sonrasında mesaj DLQ'ya taşınabilir.

Persistence

Persistence mesajın broker restart sonrasında korunmasını sağlar. Kullanılan broker ve configuration bu garantiyi etkiler. Disk tabanlı saklama latency üzerinde ek maliyet yaratabilir. Kritik mesajlar için durability ayarları önemlidir. Producer acknowledgement seviyesi de garanti davranışını etkileyebilir.

Routing

Routing mesajın hangi queue veya subscriber'a gideceğini belirler. RabbitMQ exchange türleri esnek routing sunar. Topic tabanlı sistemlerde event type veya key kullanılabilir. Gereğinden karmaşık routing kuralları bakım maliyetini artırır. Domain temelli sade bir model çoğu zaman daha sürdürülebilirdir.

Backpressure Absorbe Etmek

Consumer geçici olarak yavaşladığında broker mesajları tutabilir. Bu durum producer'ı kısa süreli yavaşlamalardan korur. Ancak broker sonsuz kapasiteye sahip değildir. Queue depth ve consumer lag alarmı kurulmalıdır. Downstream saturation devam ederse rate limiting veya load shedding gerekebilir.

En Yaygın Event-Driven Messaging Teknolojileri

Event-driven backend dünyasında farklı ihtiyaçlara hitap eden çok sayıda messaging çözümü bulunur. Apache Kafka yüksek hacimli event stream ve replay gereksinimlerinde güçlüdür. RabbitMQ esnek routing ve klasik queue işlerinde çok başarılıdır. Apache Pulsar, NATS, bulut tabanlı queue ve pub/sub servisleri de farklı operasyon modelleri sunar. Teknoloji seçerken throughput, retention, ordering, routing, ekip deneyimi ve managed service seçenekleri birlikte değerlendirilmelidir.

Apache Kafka

Apache Kafka distributed log yaklaşımıyla çalışan yüksek hacimli event streaming platformudur. Mesajlar topic ve partition yapısında saklanır. Consumer offset üzerinden kendi okuma konumunu yönetir. Retention ve replay özellikleri Kafka'yı event stream ihtiyaçlarında güçlü kılar. Partition key seçimi ordering ve yük dağılımını doğrudan etkiler.

RabbitMQ

RabbitMQ queue ve routing odaklı messaging sistemidir. Exchange, queue, binding ve routing key kavramları temel yapı taşlarıdır. Direct, topic ve fanout exchange farklı dağıtım modelleri sağlar. Manual acknowledgement ve prefetch ayarları consumer davranışını kontrol eder. Background job ve karmaşık routing senaryolarında oldukça esnek bir seçenek olabilir.

Apache Pulsar

Apache Pulsar messaging ve streaming özelliklerini bir arada sunan dağıtık bir platformdur. Topic ve subscription modeli farklı tüketim desenlerini destekler. Storage ile serving katmanlarının ayrılması ölçekleme yaklaşımını farklılaştırır. Multi-tenant ve geo-replication özellikleri bazı kurumsal ihtiyaçlarda öne çıkabilir. Seçim yaparken ekibin operasyon tecrübesi mutlaka değerlendirilmelidir.

NATS / JetStream

NATS düşük gecikmeli messaging yaklaşımıyla bilinir. JetStream persistence, replay ve stream özellikleri ekler. Basit operasyon modeli isteyen ekipler için çekici olabilir. Request-reply ve pub/sub desenlerini destekler. Yine de retention, ordering ve durability gereksinimleri ürünün gerçek davranışıyla test edilmelidir.

AWS SQS / SNS

AWS SQS managed queue hizmeti sunar. SNS ise publish/subscribe ve fan-out senaryolarında kullanılabilir. İkisi birlikte kullanıldığında bir event'in birden fazla SQS queue'ya dağıtılması mümkündür. Operasyon yükünün önemli kısmı servis sağlayıcı tarafından yönetilir. Buna karşılık delivery semantics, visibility timeout ve DLQ ayarları yine uygulama tasarımının parçasıdır.

AWS EventBridge

AWS EventBridge event routing ve event bus yaklaşımı sunar. Farklı kaynaklardan gelen event'ler rule üzerinden hedeflere yönlendirilebilir. SaaS ve AWS servis entegrasyonlarında kolaylık sağlayabilir. Schema ve event contract yönetimi yine önemlidir. Yüksek hacimli stream ihtiyacı ile iş event routing ihtiyacı birbirinden ayrılmalıdır.

Azure Service Bus

Azure Service Bus managed queue ve topic hizmeti sağlar. Enterprise messaging gereksinimlerine yönelik özellikler sunar. Queue, subscription, dead-lettering ve session gibi kavramlar farklı senaryolarda kullanılabilir. Cloud altyapısıyla sıkı entegrasyon operasyon kolaylığı sağlayabilir. Tasarım yine idempotency ve retry sorumluluğunu uygulamadan kaldırmaz.

Google Pub/Sub

Google Pub/Sub managed publish/subscribe hizmetidir. Producer topic'e mesaj yayınlar. Subscriber subscription üzerinden mesajları tüketir. Otomatik ölçekleme altyapı operasyonunu azaltabilir. Ack deadline, retry ve dead-letter policy ayarları production davranışını belirleyen önemli parametrelerdir.

Kafka mı RabbitMQ mu?

Kafka mı RabbitMQ mu sorusunun tek cümlelik doğru cevabı yoktur. Kafka distributed log, retention ve replay ağırlıklı event streaming ihtiyaçlarında güçlüdür. RabbitMQ queue, acknowledgement ve esnek routing gereksinimlerinde daha doğal bir model sunar. Kafka RabbitMQ ve Redis Streams event-driven mimari karşılaştırması yapılırken yalnızca benchmark sayılarına bakmak yerine iş semantiği değerlendirilmelidir. Sistemin mesajı geçmişte tekrar okuyup okumayacağı, routing ihtiyacı, ordering kapsamı ve operasyon bilgisi kararın merkezinde olmalıdır.

Mimari Model

Kafka append-only distributed log yaklaşımına dayanır. RabbitMQ klasik messaging ve queue modeline daha yakındır. Kafka consumer mesajı okuduğunda event log'dan hemen silinmez. RabbitMQ'da başarılı ack sonrasında mesaj çoğunlukla queue'dan kaldırılır. Bu temel fark diğer birçok davranışı etkiler.

Queue vs Distributed Log

Queue işi bir worker'a dağıtmak için doğal bir soyutlamadır. Distributed log ise event geçmişini belirli süre saklar. Consumer log içindeki offset konumunu yönetir. Geçmiş event'leri tekrar okumak kolaylaşır. İş yükünün doğası hangi modelin daha uygun olduğunu belirler.

Throughput

Kafka yüksek throughput senaryolarında güçlü performans sunar. Batching ve sequential disk yaklaşımı burada avantaj sağlar. RabbitMQ da yüksek mesaj hacmini yönetebilir. Ancak routing ve acknowledgement davranışı throughput üzerinde farklı maliyetler oluşturur. Gerçek karar sentetik benchmark yerine kendi workload testleriyle verilmelidir.

Routing

RabbitMQ exchange yapısı çok esnek routing sağlar. Routing key ve binding kurallarıyla mesajlar farklı queue'lara gönderilebilir. Kafka routing daha çok topic ve partition key üzerinden düşünülür. Karmaşık header tabanlı yönlendirme RabbitMQ'da daha doğal olabilir. Event stream kullanımında ise Kafka'nın sade topic modeli avantaj sağlayabilir.

Message Retention

Kafka mesajları tüketildikten sonra retention süresi boyunca saklayabilir. Bu davranış replay'i kolaylaştırır. RabbitMQ'da queue mesajları genellikle başarılı tüketim sonrası kaldırılır. Bazı farklı özellikler ve eklentiler davranışı değiştirebilir. Retention ihtiyacı seçimde önemli bir kriterdir.

Replay

Kafka consumer offset'i geri alarak geçmiş event'leri yeniden okuyabilir. Bu durum projection rebuild ve backfill için değerlidir. RabbitMQ klasik queue kullanımında aynı davranış doğal değildir. Replay gerekiyorsa ayrı saklama veya yeniden yayınlama stratejisi gerekebilir. Event history önemliyse bu fark ciddi avantaj yaratır.

Ordering

Kafka partition içinde ordering garantisi sunar. Aynı key aynı partition'a gönderilirse aggregate bazında sıra korunabilir. RabbitMQ queue içinde de sıralı teslim davranışı sunabilir. Paralel consumer ve retry durumları gerçek işleme sırasını etkileyebilir. Ordering garantisinin broker teslimi ile business completion sırasını aynı şey saymamak gerekir.

Consumer Model

Kafka consumer group ve partition assignment kullanır. Her partition bir group içinde tek consumer tarafından işlenir. RabbitMQ consumer'lar queue'dan mesaj alır ve acknowledgement yönetir. Prefetch mesaj dağılımını etkiler. İki modelin concurrency davranışı farklı olduğu için migration sırasında birebir eşleme yapılmamalıdır.

Operasyonel Karmaşıklık

Kafka cluster kapasitesi partition, replication ve disk davranışıyla yakından ilişkilidir. RabbitMQ'da queue dağılımı, quorum ve memory kullanımı dikkat ister. Managed hizmetler operasyon yükünü azaltabilir. Buna rağmen gözlemlenebilirlik ve incident bilgisi ekip içinde kalmalıdır. Teknoloji ekibin işletme kapasitesinin çok üzerinde seçilmemelidir.

Hangi Senaryoda Kafka?

Event geçmişini saklamak ve tekrar tüketmek önemliyse Kafka güçlü adaydır. Yüksek hacimli stream processing ihtiyaçlarında da avantajlıdır. Birden fazla bağımsız consumer group aynı event'i okuyabilir. Partition bazlı ordering birçok domain akışı için yeterlidir. Analitik, CDC ve event backbone kullanımında Kafka sık tercih edilir.

Hangi Senaryoda RabbitMQ?

Görev kuyruğu ve esnek routing gerekiyorsa RabbitMQ güçlü bir seçim olabilir. Worker tabanlı background process modellerinde kullanımı doğaldır. Direct, topic ve fanout exchange ihtiyaca göre routing sağlar. Per-message acknowledgement açık bir kontrol sunar. Replay gereksinimi düşük, routing ihtiyacı yüksek sistemlerde sade bir çözüm olabilir.

Apache Kafka Temel Kavramları

Kafka'yı doğru kullanmak için broker, topic, partition, offset ve consumer group kavramlarını anlamak gerekir. Topic event akışını, partition ise paralellik ve ordering sınırını belirler. Producer event'i partition'a yazar. Consumer kendi offset konumundan okumaya devam eder. Replication mekanizması broker arızalarına karşı dayanıklılık sağlamayı amaçlar.

Broker

Kafka broker cluster içindeki sunucu düğümüdür. Topic partition'larının verilerini saklar. Producer ve consumer isteklerini karşılar. Cluster birden fazla broker ile çalışabilir. Replication dağılımı broker failure durumunda kullanılabilirliği etkiler.

Topic

Topic ilgili event akışının mantıksal ismidir. Producer belirli topic'e mesaj yazar. Consumer group topic'i okuyabilir. Topic partition'lardan oluşur. Naming ve retention politikası domain gereksinimleriyle uyumlu olmalıdır.

Partition

Partition topic içindeki sıralı log parçasıdır. Paralel tüketim kapasitesini artırır. Aynı partition içindeki event'ler offset sırasına sahiptir. Message key hangi partition'ın seçileceğini etkileyebilir. Partition sayısı sonradan artırıldığında key dağılımı değişebilir.

Offset

Offset partition içindeki mesaj konumunu temsil eder. Consumer işlediği konumu kaydeder. Restart sonrasında bu konumdan devam edebilir. Yanlış commit sırası mesaj kaybı veya tekrar işlemeye neden olabilir. Processing tamamlandıktan sonra commit etmek at-least-once davranışını destekler.

Producer

Kafka producer event'leri topic'e gönderir. Message key partition seçimini etkileyebilir. Acknowledgement ayarları durability davranışını belirler. Batching throughput'u artırabilir. Retry ve idempotent producer ayarları duplicate riskini azaltmada önemlidir.

Consumer

Kafka consumer partition'lardan event okur. Kendi group üyeliği üzerinden partition assignment alır. Mesajı işledikten sonra offset commit edebilir. Consumer crash olduğunda partition başka instance'a atanabilir. Bu durum duplicate processing ihtimalini artırabilir.

Consumer Group

Consumer Group aynı logical uygulamanın instance'larını bir araya getirir. Partition'lar grup üyeleri arasında dağıtılır. Group içindeki paralellik partition sayısıyla sınırlıdır. Yeni consumer gruba katıldığında rebalance oluşabilir. Farklı group'lar aynı event'i bağımsız tüketebilir.

Replication

Replication partition verisinin birden fazla broker üzerinde kopyalanmasını sağlar. Leader partition yazma ve okuma isteklerini yönetir. Replica'lar failure durumunda devreye girebilir. Replication factor dayanıklılık ve storage maliyetini birlikte etkiler. Multi-zone dağılımı zone failure senaryolarında önemlidir.

RabbitMQ Temel Kavramları

RabbitMQ'da producer mesajı doğrudan queue'ya değil çoğu zaman exchange'e gönderir. Exchange binding kurallarına göre mesajı queue'lara yönlendirir. Routing key bu kararda kullanılabilir. Consumer queue'dan mesaj alır ve acknowledgement gönderir. Bu model routing gereksinimlerini uygulama kodundan ayırmak için güçlü bir yapı sunar.

Producer

RabbitMQ producer mesaj üretip exchange'e yayınlar. Mesaj metadata ve routing key içerebilir. Publisher confirm kullanımı delivery güvenilirliğini artırabilir. Bağlantı hatalarında retry politikası gerekir. Producer'ın duplicate yayın ihtimalini hesaba katması önemlidir.

Exchange

Exchange gelen mesajları queue'lara yönlendirir. Direct, topic, fanout ve headers türleri farklı routing davranışları sağlar. Exchange mesajı kendi üzerinde uzun süre saklamaz. Queue binding yoksa mesaj kaybolabilir veya alternate davranış uygulanabilir. Topology production öncesinde açık biçimde tanımlanmalıdır.

Queue

Queue consumer tarafından işlenecek mesajları tutar. Durable queue broker restart sonrasında varlığını koruyabilir. Mesaj durability ayarları ayrıca önemlidir. Queue depth backpressure için kritik metriktir. Sürekli büyüyen queue consumer kapasitesinin yetersiz olduğunu gösterebilir.

Binding

Binding exchange ile queue arasındaki routing ilişkisidir. Routing key veya pattern içerebilir. Topic exchange kullanımında wildcard desenleri desteklenebilir. Binding sayısı arttıkça topology yönetimi zorlaşabilir. İsimlendirme ve dokümantasyon operasyon ekibine yardımcı olur.

Routing Key

Routing Key mesajın hangi queue'lara yönlendirileceğini etkiler. Direct exchange tam eşleşme kullanabilir. Topic exchange pattern tabanlı eşleşme sunar. Domain event isimleri routing key olarak kullanılabilir. Çok teknik ve değişken key yapıları uzun vadede coupling oluşturabilir.

Consumer

Consumer queue'dan mesaj alır ve business operation'ı çalıştırır. Manual ack güvenilir processing için sık tercih edilir. Consumer hata aldığında nack ve requeue davranışı uygulanabilir. Poison message sonsuz döngüye girmemelidir. Retry limitinden sonra DLQ kullanmak daha kontrollüdür.

Acknowledgement

Acknowledgement mesajın consumer tarafından başarıyla işlendiğini broker'a bildirir. Auto ack mesaj alındığı anda başarılı kabul edebilir. Manual ack business işleminden sonra gönderilebilir. Consumer crash olursa ack edilmemiş mesaj yeniden teslim edilebilir. Bu nedenle idempotent consumer tasarımı önemini korur.

RabbitMQ Exchange Türleri

RabbitMQ exchange türleri mesaj routing davranışını belirler. Direct exchange exact routing key eşleşmesine dayanır. Topic exchange wildcard destekleyen pattern routing sunar. Fanout exchange routing key'e bakmadan bağlı queue'lara mesajı dağıtır. Headers exchange ise header değerlerine göre routing ihtiyacı olduğunda kullanılabilir.

Direct

Direct exchange mesajı routing key ile eşleşen queue'ya gönderir. Yapısı sade ve tahmin edilebilirdir. Belirli iş tiplerini farklı queue'lara ayırmak için kullanılabilir. Çok sayıda key varsa yönetim dikkat ister. Naming convention routing modelini daha anlaşılır kılar.

Topic

Topic exchange pattern tabanlı routing sunar. Noktayla ayrılmış routing key parçaları wildcard ile eşleştirilebilir. Örneğin order.created.eu gibi desenler kullanılabilir. Bu yapı esnektir. Gereğinden geniş wildcard kullanımı istemeyen consumer'ların mesaj almasına neden olabilir.

Fanout

Fanout exchange mesajı bağlı tüm queue'lara gönderir. Routing key dikkate alınmaz. Bir event'i birden fazla bağımsız işleyiciye dağıtmak için uygundur. Her consumer için ayrı queue oluşturulabilir. Broadcast benzeri ihtiyaçlarda sade bir model sunar.

Headers

Headers exchange routing kararını message header alanlarına göre verir. Routing key yerine header değerleri kullanılır. Birden fazla kriterle eşleşme yapılabilir. Esnek olsa da topology anlaşılmasını zorlaştırabilir. Gerçek ihtiyaç yoksa daha sade exchange türleri tercih edilebilir.

Hangi Routing Modelinde Hangisi Kullanılır?

Exact key eşleşmesi gerekiyorsa direct exchange uygundur. Pattern bazlı domain routing için topic exchange kullanılabilir. Mesajın tüm bağlı consumer queue'larına gitmesi gerekiyorsa fanout daha doğaldır. Header içeriğine göre routing özel ihtiyaçlarda değerlendirilebilir. Seçim yapılırken operasyon ekibinin topology'yi kolay anlayabilmesi de önemlidir.

Event Delivery Semantics Nedir?

Delivery semantics bir mesajın consumer'a kaç kez ulaşabileceğine dair beklenen davranışı açıklar. At-most-once mesaj kaybını kabul ederek duplicate riskini azaltır. At-least-once mesajın en az bir kez işlenmesini hedefler, duplicate ihtimalini normal kabul eder. Exactly-once ise çoğu zaman yalnızca belirli sistem sınırlarında anlamlıdır. Business guarantee ile broker delivery guarantee aynı şey değildir ve production tasarımında bu fark açık tutulmalıdır.

At-Most-Once

At-Most-Once mesajın sıfır veya bir kez işlenebileceği modeli ifade eder. Retry yapılmadığında duplicate riski düşer. Buna karşılık failure sırasında mesaj kaybı yaşanabilir. Telemetri gibi bazı düşük kritik akışlarda kabul edilebilir. Finansal veya kritik iş akışlarında çoğu zaman yeterli değildir.

At-Least-Once

At-Least-Once mesajın başarı sağlanana kadar yeniden teslim edilebilmesini kabul eder. Duplicate message bu modelin doğal sonucudur. Consumer idempotent tasarlanmalıdır. Ack veya offset commit işlemi business operation sonrasında yapılmalıdır. Event-driven sistemlerde en yaygın güvenilirlik modellerinden biridir.

Exactly-Once

Exactly-Once terimi dikkatli yorumlanmalıdır. Broker belirli sınırlar içinde duplicate yazmayı veya tüketimi kontrol edebilir. Ancak database ve external API side effect'leri ayrı sistemlerdir. Bu nedenle business dünyasında tam exactly-once garantisi çok daha geniş bir problem hâline gelir. Çoğu sistem pratikte at-least-once delivery ile idempotent processing yaklaşımını kullanır.

Delivery Guarantee ile Business Guarantee Arasındaki Fark

Broker bir mesajı tek kez teslim ettiğini iddia edebilir. Ancak consumer mesajı aldıktan sonra database commit yapıp ack göndermeden crash olabilir. Aynı mesaj tekrar geldiğinde business side effect ikinci kez oluşabilir. Bu nedenle transport garantisi business operation garantisi değildir. Güvenilir tasarım tüm zinciri birlikte ele almalıdır.

At-Most-Once Delivery

At-Most-Once yaklaşımı düşük gecikme ve basitlik sunabilir. Mesaj tekrar gönderilmediği için duplicate processing ihtimali azalır. Bunun bedeli message loss riskidir. Kritik olmayan telemetry veya hızlı sampling akışlarında tercih edilebilir. İş açısından kaybın maliyeti yüksekse bu model dikkatle değerlendirilmelidir.

Mesaj Kaybı Riski

Consumer mesajı aldıktan sonra crash olursa mesaj yeniden gelmeyebilir. Broker acknowledgement stratejisi bu riski etkiler. Network failure sırasında durum belirsiz kalabilir. Kaybın kabul edilebilirliği business gereksinimine bağlıdır. Kritik event'lerde bu risk çoğu zaman kabul edilmez.

Duplicate Olmaması

Retry yapılmadığında duplicate ihtimali ciddi biçimde azalır. Bu bazı basit akışlarda avantajdır. Ancak message loss riski bunun karşılığında artar. Duplicate önlemek için güvenilirliği feda etmek çoğu business process için doğru değildir. İdempotency çoğu zaman daha güvenli bir çözümdür.

Hangi İşlerde Kabul Edilebilir?

Tekil telemetri örnekleri kaybolduğunda business sonucu değişmiyorsa kullanılabilir. Yüksek frekanslı ölçümlerde birkaç mesaj kaybı kabul edilebilir olabilir. Geçici UI activity event'leri de benzer şekilde değerlendirilebilir. Ödeme, sipariş veya stok işlemleri için uygunluğu düşüktür. Karar mutlaka veri kaybının iş etkisine göre verilmelidir.

At-Least-Once Delivery

At-Least-Once production event-driven sistemlerde en sık karşılaşılan teslim modelidir. Mesaj başarısız işlem sonrası yeniden teslim edilebilir. Bu durum veri kaybı riskini azaltırken duplicate ihtimalini artırır. Consumer'ın idempotent olması bu yüzden temel gereksinime dönüşür. Event-driven sistemlerde retry idempotency dead letter queue ve event consistency yönetimi birlikte tasarlanmadığında at-least-once davranışı ciddi yan etkiler oluşturabilir.

Retry

Retry geçici hatalarda işlemin tekrar denenmesini sağlar. Network timeout veya 503 bunun tipik örnekleridir. Retry sınırsız yapılmamalıdır. Exponential backoff ve jitter downstream sistemleri korur. Maksimum deneme sonrasında DLQ veya manual intervention gerekebilir.

Redelivery

Redelivery aynı mesajın consumer'a yeniden verilmesidir. Consumer crash veya ack kaybı bunu tetikleyebilir. Mesaj daha önce business side effect üretmiş olabilir. Bu nedenle redelivery duplicate processing riskini doğurur. Event ID tabanlı kontrol güvenilir bir savunma sağlar.

Duplicate Mesajların Normal Olması

At-least-once sistemlerde duplicate mesaj istisna olarak görülmemelidir. Network ve process failure bunu doğal olarak üretir. Tasarım baştan bu varsayımla yapılmalıdır. Aynı event'in iki kez gelmesi alarm sebebi olmak zorunda değildir. Asıl önemli olan business sonucunun iki kez uygulanmamasıdır.

Consumer'ın Idempotent Olması

Idempotent consumer aynı event'i tekrar aldığında son durumu değiştirmemelidir. Event ID daha önce işlenen mesajı tanımak için kullanılabilir. Unique constraint yarış koşullarına karşı güvenli koruma sağlar. Deduplication kaydı business transaction ile birlikte tutulmalıdır. Böylece crash ve retry durumlarında tutarlı davranış sağlanır.

Exactly-Once Gerçekte Ne Anlama Gelir?

Exactly-once ifadesi çoğu zaman pazarlama cümlesi kadar dikkatli okunmalıdır. Bir broker kendi log sınırları içinde exactly-once benzeri processing semantiği sağlayabilir. Ancak consumer database'e yazıyor veya harici ödeme API'si çağırıyorsa garanti kapsamı genişler. İki ayrı sistemi tek atomik transaction ile bağlamak kolay değildir. Production tasarımında hedef genellikle duplicate teslimi kabul edip business side effect'i idempotent hâle getirmektir.

Broker Seviyesinde Exactly-Once

Broker belirli producer ve consumer işlemlerinde duplicate kontrolü uygulayabilir. Kafka transaction mekanizmaları bazı stream işlem akışlarında faydalıdır. Ancak bu garanti broker sınırları içinde değerlendirilmelidir. Harici database aynı transaction'a doğal olarak dahil değildir. Sistem açıklamalarında bu sınır açıkça belirtilmelidir.

Processing Semantics

Processing semantics mesajın tüketilip yeni sonuç üretilmesi davranışını kapsar. Consume-transform-produce akışı bazı platformlarda transaction ile yönetilebilir. Bu durumda output topic'teki duplicate etkisi azaltılabilir. Fakat external side effect varsa durum değişir. Business guarantee her zaman uçtan uca değerlendirilmelidir.

Database Side Effect

Consumer mesajı aldıktan sonra database row ekleyebilir. Commit başarılı olup ack başarısız olursa mesaj tekrar gelebilir. Aynı insert ikinci kez çalışırsa duplicate veri oluşabilir. Unique constraint ve processed message table bunu engelleyebilir. Database transaction idempotency'nin önemli parçasıdır.

External API Side Effect

Harici API çağrısı idempotency açısından daha zor olabilir. Ödeme sağlayıcısına aynı charge isteğini iki kez göndermek ciddi sonuç doğurabilir. API idempotency key destekliyorsa event ID bu amaçla kullanılabilir. Destek yoksa local state ve reconciliation gerekebilir. Replay sırasında external side effect'ler özel olarak kontrol edilmelidir.

“Exactly Once” İddialarının Sınırları

Exactly-once iddiası hangi sınırda geçerli olduğu belirtilmeden eksik kalır. Broker log'u, database ve external API farklı failure domain'leridir. Birindeki garanti diğerine otomatik taşınmaz. Bu nedenle mimari dokümanda guarantee scope yazılmalıdır. Business ekiplerine de kullanıcı açısından gerçek davranış açık biçimde anlatılmalıdır.

Idempotency Nedir?

Idempotency aynı işlemin bir veya birden fazla kez çağrıldığında aynı final state'i üretmesini ifade eder. Event-driven sistemlerde duplicate delivery nedeniyle kritik bir tasarım ilkesidir. Aynı OrderPaid event'i iki kez alınsa bile iki fatura oluşturulmaması gerekir. Idempotency doğal business constraint üzerinden veya explicit deduplication tablosuyla sağlanabilir. Sağlam consumer tasarımının en önemli özelliklerinden biri duplicate event'i güvenli biçimde karşılayabilmesidir.

Aynı Event'i İki Kez İşlemek

Aynı event birden fazla kez consumer'a ulaşabilir. İlk işlem tamamlanmış olsa bile ack kaybı redelivery oluşturabilir. Consumer mesajı yeni event sanmamalıdır. Event ID kontrol edilerek daha önce işlendiği anlaşılabilir. Bu davranış unit ve integration testlerde özellikle doğrulanmalıdır.

Aynı Sonucu Üretmek

Idempotent işlem tekrarlandığında final state değişmez. Örneğin status değerini PAID yapmak doğal olarak idempotent olabilir. Fakat balance değerine tekrar tutar eklemek idempotent değildir. Business operation'ın yapısı analiz edilmelidir. Gerektiğinde işlem anahtarı veya unique constraint eklenmelidir.

Doğal Idempotency

Bazı işlemler yapısı gereği idempotent olabilir. Bir alanı belirli değere set etmek buna örnektir. Aynı update tekrarlandığında state değişmez. Buna rağmen diğer side effect'ler kontrol edilmelidir. E-posta gönderimi aynı operation içinde hâlâ duplicate olabilir.

Explicit Idempotency

Explicit idempotency event ID veya business idempotency key kullanır. ProcessedMessages gibi tablo oluşturulabilir. Aynı ID için unique constraint uygulanır. Consumer transaction içinde hem business işlem hem de processed kaydını yazar. Duplicate event geldiğinde güvenli biçimde atlanır.

Idempotent Consumer Pattern

Idempotent Consumer Pattern duplicate delivery'nin business side effect üretmesini önlemeyi amaçlar. Consumer her mesaj için benzersiz event ID kontrol eder. İşlenmiş mesajlar kalıcı bir tabloda tutulabilir. Unique constraint paralel consumer yarışlarında önemli koruma sağlar. Deduplication kaydı ile business update aynı transaction içinde yapılırsa crash senaryolarında daha güvenilir davranış elde edilir.

Event ID

Her event global veya uygun scope içinde benzersiz ID taşımalıdır. UUID veya benzeri değerler kullanılabilir. Consumer bu ID üzerinden duplicate kontrolü yapar. Event replay sırasında aynı event aynı ID'yi korumalıdır. Yeniden publish edilirken rastgele yeni ID üretmek deduplication davranışını bozabilir.

Processed Messages Table

Processed Messages Table işlenen event ID'lerini saklar. Consumer adı veya handler bilgisi de tutulabilir. Böylece aynı event farklı consumer'lar tarafından bağımsız işlenebilir. Retention politikası tablo büyümesini kontrol eder. Cleanup yapılırken replay gereksinimleri dikkate alınmalıdır.

Unique Constraint

Unique constraint duplicate kaydın database seviyesinde engellenmesini sağlar. Sadece uygulama içi önce kontrol et sonra insert yaklaşımı yarış koşulu oluşturabilir. İki consumer aynı event'i aynı anda görebilir. Database unique constraint bu durumda güvenli bariyer olur. Conflict sonucu duplicate event'in işlendiği anlaşılabilir.

İşlem ve Deduplication'ı Aynı Transaction'da Yapmak

Business update ile deduplication kaydı ayrı transaction'larda yapılırsa arada crash oluşabilir. Bu durum aynı event'in tekrar side effect üretmesine yol açabilir. İki kayıt aynı database transaction içinde tutulmalıdır. Commit başarılı olduğunda ikisi birlikte kalıcı olur. Transaction rollback olduğunda event yeniden güvenle denenebilir.

Duplicate Event'i Sessizce Atlamak

Daha önce başarıyla işlenen event yeniden geldiğinde çoğu zaman hata üretmeye gerek yoktur. Consumer duplicate olduğunu metric veya debug log olarak kaydedebilir. Business operation tekrar çalıştırılmaz. Mesaj başarılı kabul edilip ack edilebilir. Duplicate oranı beklenmedik biçimde yükselirse altyapı sorunu ayrıca incelenebilir.

Inbox Pattern Nedir?

Inbox Pattern gelen event'lerin önce kalıcı bir store içine kaydedilip daha sonra işlenmesini sağlar. Bu yaklaşım consumer tarafındaki güvenilirliği artırabilir. Inbox kaydı event ID, payload ve processing state gibi bilgiler içerir. Worker inbox kayıtlarını işleyip başarılı veya hatalı duruma geçirir. Retry, deduplication ve audit gereksinimleri tek yapı üzerinde daha görünür hâle gelir.

Gelen Event'i Önce Kalıcı Olarak Saklamak

Consumer broker mesajını aldığında önce inbox tablosuna yazabilir. Bu kayıt local transaction sınırına girer. Event kaybolmadan daha sonra işlenebilir. Broker acknowledgement uygun noktada yapılmalıdır. Tasarım delivery semantics ile uyumlu olmalıdır.

Inbox Table

Inbox Table alınan event'lerin yerel kaydını tutar. Event ID unique alan olabilir. Payload, timestamp ve source bilgileri saklanabilir. Processing status operasyon görünürlüğü sağlar. Table büyümesi için retention ve cleanup politikası gerekir.

Processing State

Inbox kaydı pending, processing, completed veya failed gibi state taşıyabilir. Worker state geçişlerine göre mesajı işler. Crash sonrası pending veya stuck kayıtlar tekrar seçilebilir. State machine basit ve anlaşılır tutulmalıdır. Gereğinden fazla durum operasyon hatalarını artırabilir.

Retry

Failed inbox kayıtları kontrollü retry politikasına alınabilir. Attempt count ve next retry time tutulabilir. Exponential backoff kullanılabilir. Non-retryable hata doğrudan terminal state'e gidebilir. Belirli eşikten sonra manual investigation gerekebilir.

Duplicate Detection

Inbox table event ID üzerinden duplicate detection sağlar. Aynı event tekrar geldiğinde ikinci kayıt insert edilemez. Consumer bunun daha önce alındığını anlayabilir. İşlenmiş kayıt completed ise mesaj ack edilebilir. Pending kayıt varsa mevcut processing süreci devam eder.

Inbox Cleanup

Inbox table sonsuza kadar büyümemelidir. Completed kayıtlar retention politikasına göre temizlenebilir. Ancak replay ve audit gereksinimleri göz önünde tutulmalıdır. Cleanup job kendi monitoring metriklerine sahip olmalıdır. Yanlış cleanup aktif işlemleri silmemelidir.

Transactional Outbox Pattern Nedir?

Transactional Outbox Pattern business database değişikliği ile event üretimi arasındaki dual-write problemini çözmek için kullanılan temel desendir. Uygulama business table güncellemesi ile outbox kaydını aynı database transaction içinde yapar. Transaction commit olduğunda ikisi birlikte kalıcı olur. Ayrı bir relay veya CDC süreci outbox event'lerini broker'a yayınlar. Bu yaklaşım producer reliability açısından production event-driven sistemlerde en güçlü pratiklerden biridir.

Dual-Write Problemi

Dual-write aynı business operation içinde iki bağımsız sisteme yazmayı ifade eder. Örneğin database commit ile broker publish ayrı işlemlerdir. Biri başarılı olup diğeri başarısız olabilir. Bu durum state ile event arasında tutarsızlık oluşturur. Outbox iki yazımı tek database transaction sınırında birleştirir.

Business Table

Business Table asıl domain state'ini saklar. Sipariş, ödeme veya kullanıcı kaydı buna örnektir. Transaction sırasında bu tablo güncellenir. Aynı transaction içinde outbox row da eklenir. Böylece event iş state'inden bağımsız kalmaz.

Outbox Table

Outbox Table yayınlanacak event'leri geçici olarak saklar. Event ID, type, payload ve created time alanları içerebilir. Publish state veya relay metadata tutulabilir. Table cleanup stratejisi gerekir. Outbox'ı kalıcı event store sanmak doğru değildir.

Tek Database Transaction

Business update ve outbox insert aynı transaction içinde yapılır. Commit başarılıysa iki kayıt da kalır. Rollback olursa ikisi de kaybolur. Böylece database state değişip event'in hiç oluşmaması önlenir. Bu özellik Outbox deseninin ana değeridir.

Message Relay

Message Relay outbox kayıtlarını broker'a taşıyan bileşendir. Polling veya CDC yaklaşımı kullanılabilir. Relay publish başarısını takip etmelidir. Aynı event'i birden fazla kez yayınlama ihtimali vardır. Bu nedenle consumer yine idempotent olmalıdır.

Broker'a Event Publish

Relay outbox event'ini broker'a publish eder. Publish confirmation alınması önemlidir. Confirmation sonrası outbox kaydı processed olarak işaretlenebilir. Crash iki adım arasında oluşursa event yeniden yayınlanabilir. At-least-once publish davranışı bu nedenle olağandır.

Dual-Write Problemi

Dual-write event-driven mimaride en kritik veri tutarlılığı problemlerinden biridir. Database ve broker birbirinden bağımsız transaction sistemleridir. Birine yazıp diğerine yazamamak state ile event'in ayrışmasına yol açar. İki sistem arasında distributed transaction kullanmak her platformda pratik değildir. Transactional Outbox bu problemi uygulama tarafında yönetilebilir ve gözlemlenebilir bir modele dönüştürür.

Önce Database Sonra Broker

Uygulama önce database'e commit edip sonra broker'a publish edebilir. Database başarılı olur. Ardından process crash yaşanabilir. Event hiç yayınlanmadan business state değişmiş olur. Downstream servisler bu değişikliği öğrenemez.

Commit Sonrası Process Crash

Commit tamamlandığı anda business state kalıcıdır. Process broker publish öncesinde kapanabilir. Uygulama tekrar başladığında hangi event'in eksik olduğunu bilmeyebilir. Manuel reconciliation gerekebilir. Outbox kaydı bu boşluğu ortadan kaldırır.

Önce Broker Sonra Database

Uygulama önce event yayınlayıp sonra database transaction yapabilir. Event consumer'lara ulaşabilir. Database işleminde hata oluşabilir. Downstream servisler gerçekte commit olmamış bir olaya tepki verir. Bu durum ciddi veri tutarsızlığı oluşturur.

Event Yayınlandı Ama Transaction Rollback

Broker event'i başarıyla kabul etmiş olabilir. Ardından local transaction rollback olabilir. Consumer event'i gerçek bir business fact sanır. Geri alma için ek compensation gerekebilir. Event geçmişte gerçekleşmiş bir gerçek olmalıdır, gerçekleşmeyen niyeti temsil etmemelidir.

Neden İki Ayrı Sisteme Atomik Yazmak Zordur?

Database ve broker farklı transaction coordinator'lara sahiptir. Tek ACID transaction altında çalışmaları doğal değildir. Distributed transaction protokolleri operasyon ve availability maliyeti getirir. Birçok modern sistem bunun yerine eventual consistency desenlerini kullanır. Outbox ve idempotent consumer bu yüzden yaygınlaşmıştır.

Outbox Event'leri Broker'a Nasıl Aktarılır?

Outbox kayıtlarını broker'a taşımak için en yaygın iki yöntem polling publisher ve Change Data Capture yaklaşımıdır. Polling publisher belirli aralıklarla outbox tablosunu sorgular. CDC ise database transaction log'unu okuyarak değişiklikleri stream'e dönüştürür. Debezium bu alanda yaygın kullanılan araçlardan biridir. Seçim operasyon tecrübesi, latency ihtiyacı, database özellikleri ve bakım maliyetine göre yapılmalıdır.

Polling Publisher

Polling Publisher outbox tablosunu periyodik olarak sorgular. Yayınlanmamış kayıtları seçer ve broker'a gönderir. Uygulaması anlaşılır ve kontrollüdür. Çok sık polling database yükünü artırabilir. Batch boyutu ve interval dikkatle ayarlanmalıdır.

Transaction Log Tailing

Transaction Log Tailing database'in değişiklik log'unu takip eder. Uygulama tablosunu sürekli sorgulamak yerine log akışı okunur. Daha düşük polling yükü sağlayabilir. Database'e özgü operasyon bilgisi gerektirir. Offset ve connector state güvenilir biçimde yönetilmelidir.

Change Data Capture

Change Data Capture database değişikliklerini event stream'e dönüştürür. WAL veya binlog gibi transaction log kaynakları kullanılabilir. Outbox table değişimleri güvenilir biçimde yakalanabilir. Connector event'i broker'a aktarır. Schema değişiklikleri ve connector recovery planı ayrıca yönetilmelidir.

Debezium

Debezium açık kaynak CDC platformudur. PostgreSQL, MySQL ve farklı database sistemleriyle çalışabilir. Transaction log değişikliklerini Kafka gibi platformlara aktarabilir. Outbox Event Router yaklaşımı event yayınlamayı kolaylaştırabilir. Operasyon sırasında connector lag ve offset state izlenmelidir.

Polling vs CDC Karşılaştırması

Polling daha sade uygulama modeli sunabilir. CDC düşük latency ve daha sürekli akış sağlayabilir. Polling database query yükü oluşturur. CDC ise connector ve transaction log operasyon bilgisi gerektirir. Ekibin yönetebildiği güvenilir çözüm çoğu zaman teorik olarak en gelişmiş çözümden daha değerlidir.

Change Data Capture (CDC) Nedir?

CDC database üzerinde gerçekleşen insert, update ve delete değişikliklerini yakalayıp event akışına dönüştürme yaklaşımıdır. Uygulama kodundan bağımsız değişiklik takibi sağlayabilir. PostgreSQL WAL veya MySQL Binlog gibi transaction log kaynakları kullanılabilir. CDC özellikle Outbox relay, analitik veri akışı ve data synchronization senaryolarında güçlüdür. Bununla birlikte raw database change ile business event aynı şey değildir ve contract tasarımı buna göre yapılmalıdır.

Database Transaction Log

Database transaction log kalıcı değişikliklerin kayıtlarını tutar. Recovery mekanizmaları bu log'a dayanabilir. CDC araçları log değişikliklerini okuyabilir. Böylece uygulama tabloları sürekli polling yapmak zorunda kalmaz. Log retention ve connector offset ayarları kritik önem taşır.

PostgreSQL WAL

PostgreSQL Write-Ahead Log transaction değişikliklerini kaydeder. Logical replication CDC kullanımına temel olabilir. Connector uygun replication slot üzerinden değişiklikleri okuyabilir. Slot geride kalırsa disk kullanımı büyüyebilir. Operasyon ekibi lag ve slot durumunu izlemelidir.

MySQL Binlog

MySQL binary log database değişikliklerini kaydeder. CDC connector'ları binlog üzerinden değişiklikleri okuyabilir. Binlog retention connector kesintilerine dayanacak şekilde ayarlanmalıdır. Format seçimi CDC davranışını etkileyebilir. Recovery sırasında doğru position bilgisinin korunması gerekir.

Debezium

Debezium transaction log değişikliklerini event olarak yayınlayan connector altyapısı sunar. Snapshot ve streaming modları farklı başlangıç senaryolarını destekler. Schema değişikliklerini de takip edebilir. Connector health ve lag metrikleri izlenmelidir. Production upgrade süreçleri test ortamında doğrulanmalıdır.

Database Değişikliklerini Event Stream'e Dönüştürmek

Her database değişikliğini doğrudan business event saymak doğru değildir. Raw CDC event'i tablo ve column yapısına bağlıdır. Integration consumer'lar bu yapıya bağlanırsa database schema coupling oluşur. Outbox table business event contract'ını daha kontrollü üretir. CDC yalnızca güvenilir taşıma mekanizması olarak kullanılabilir.

Outbox + Inbox Birlikte Kullanıldığında Ne Sağlanır?

Outbox producer tarafında event'in business transaction ile birlikte kalıcı olmasını sağlar. Inbox consumer tarafında alınan event'in güvenli biçimde kaydedilmesine yardımcı olur. İki desen birlikte kullanıldığında producer ve consumer failure senaryoları daha yönetilebilir hâle gelir. Duplicate processing kontrolü, replay ve auditability güçlenir. Yine de exactly-once business guarantee otomatik oluşmaz, side effect'ler ve external API davranışı ayrıca ele alınmalıdır.

Producer Reliability

Outbox database state ile event kaydını tek transaction içinde tutar. Böylece commit olmuş state'in event'i kaybolmaz. Relay daha sonra broker'a publish eder. Publish tekrar edebilir. Consumer idempotency bu nedenle hâlâ gereklidir.

Consumer Reliability

Inbox alınan event'i kalıcı olarak saklar. Consumer processing daha sonra yapılabilir. Crash sonrası incomplete kayıtlar yeniden denenebilir. Processing state görünür hâle gelir. Bu yapı operasyon ekiplerine daha iyi recovery imkânı sağlar.

Duplicate Processing Kontrolü

Inbox event ID üzerinden duplicate mesajları tanıyabilir. Aynı event ikinci kez kaydedilemez. Business operation yalnızca ilk kayıt üzerinden yürütülür. Unique constraint yarış koşullarını önler. Bu yaklaşım at-least-once delivery ile iyi uyum sağlar.

Reprocessing

Inbox geçmiş event'leri yeniden işlemek için kontrollü kaynak sağlayabilir. Failed veya belirli tarih aralığındaki kayıtlar seçilebilir. Reprocessing side effect güvenliğiyle birlikte düşünülmelidir. Event replay ve inbox retry birbirinden ayrılmalıdır. Operatörlerin kullanacağı tooling açık olmalıdır.

Auditability

Outbox ve Inbox event hareketleri için yerel audit izi sağlar. Hangi event'in ne zaman üretildiği görülebilir. Consumer'ın ne zaman işlediği takip edilebilir. Incident analizinde bu bilgiler değerlidir. Retention politikası audit ihtiyacına göre belirlenmelidir.

Event Ordering Nedir?

Event ordering olayların belirli bir sırada işlenmesi gereksinimini ifade eder. Her event için global sıra sağlamak çoğu dağıtık sistemde pahalıdır. Daha gerçekçi yaklaşım ordering kapsamını aggregate veya partition seviyesinde sınırlamaktır. Sipariş event'lerinin kendi sipariş ID'si içinde sıralı olması çoğu zaman yeterlidir. Ordering gereksinimi tanımlanırken throughput ve paralellik maliyeti açıkça değerlendirilmelidir.

Global Ordering

Global Ordering tüm event'lerin tek sıra halinde ilerlemesini ister. Bu yaklaşım paralelliği ciddi biçimde sınırlar. Tek partition benzeri model gerekebilir. Büyük sistemlerde throughput darboğazı oluşturabilir. İş gereksinimi gerçekten istemiyorsa global ordering uygulanmamalıdır.

Partition-Level Ordering

Partition-Level Ordering aynı partition içindeki event sırasını korur. Kafka bunun doğal örneğidir. Farklı partition'lar paralel ilerleyebilir. Bu sayede throughput ile ordering arasında denge sağlanır. Message key doğru seçilmelidir.

Aggregate-Level Ordering

Aggregate-Level Ordering aynı entity'ye ait event'lerin sırada kalmasını hedefler. Order ID veya Account ID key olarak kullanılabilir. Farklı aggregate'lar paralel işlenebilir. Bu model çoğu business system için yeterlidir. Hot key problemi yine değerlendirilmelidir.

Ordering'in Ölçeklenebilirlik Maliyeti

Daha güçlü ordering daha az paralellik anlamına gelebilir. Tek partition tüm trafiği sınırlayabilir. Consumer sayısını artırmak fayda sağlamayabilir. Ordering scope daraltıldığında sistem daha iyi ölçeklenebilir. Bu nedenle gereksinim teknik ekip değil business kuralı üzerinden tanımlanmalıdır.

Kafka'da Ordering Nasıl Sağlanır?

Kafka partition içinde mesaj sırasını korur. Aynı aggregate için aynı message key kullanıldığında event'ler aynı partition'a yönlendirilebilir. Consumer group içinde ilgili partition bir consumer tarafından işlenir. Bu yapı aggregate-level ordering için güçlü bir temel sunar. Ancak consumer'ın paralel thread kullanması veya retry mesajını başka akışa taşıması business completion sırasını değiştirebilir.

Partition

Partition sıralı log birimidir. Her mesaj offset ile konumlanır. Consumer offset sırasıyla mesajları okuyabilir. Paralel tüketim partition'lar arasında gerçekleşir. Partition içindeki processing davranışı uygulama tarafından bozulmamalıdır.

Message Key

Message Key partition seçimini belirleyebilir. Aynı key genellikle aynı partition'a gider. Order ID gibi aggregate key kullanımı yaygındır. Key dağılımının dengeli olması önemlidir. Tek bir hot key partition yükünü artırabilir.

Aynı Aggregate İçin Aynı Partition

Aynı aggregate event'leri aynı partition'a gönderildiğinde sıra korunabilir. OrderCreated ve OrderPaid aynı Order ID key'i kullanabilir. Consumer bunları offset sırasıyla alır. Bu tasarım final state hesaplamasını kolaylaştırır. Key değişirse ordering garantisi bozulabilir.

Consumer Group

Consumer group partition'ları instance'lar arasında dağıtır. Bir partition aynı anda group içinde tek consumer'a atanır. Böylece partition sırası korunur. Rebalance sırasında kısa duraklamalar olabilir. Consumer processing idempotent kalmalıdır.

Paralel Consumer ve Ordering Dengesi

Daha fazla consumer daha yüksek paralellik sağlayabilir. Ancak consumer sayısı partition sayısını aştığında ek instance boş kalır. Partition sayısını artırmak ordering key dağılımını etkileyebilir. Aynı partition içinde paralel processing dikkat ister. Throughput hedefi ordering requirement ile birlikte test edilmelidir.

Partition Key Nasıl Seçilir?

Partition key event ordering ve yük dağılımını aynı anda etkiler. User ID, Order ID veya Account ID gibi yüksek cardinality değerler çoğu zaman iyi başlangıç noktalarıdır. Tenant ID bazı multi-tenant sistemlerde doğal görünse de büyük tenant'lar hot partition oluşturabilir. Key'in business ordering scope'unu yansıtması gerekir. Distribution gerçek production verisine benzer workload ile test edilmelidir.

User ID

User ID kullanıcı bazında ordering gerektiğinde kullanılabilir. Aynı kullanıcı event'leri aynı partition'a gider. Çok sayıda kullanıcı varsa dağılım genellikle iyidir. Çok aktif tek kullanıcı sınırlı hot spot oluşturabilir. Gizlilik açısından key'in doğrudan loglanması ayrıca değerlendirilmelidir.

Order ID

Order ID sipariş yaşam döngüsü için doğal ordering key'idir. Aynı sipariş event'leri sırada tutulur. Farklı siparişler paralel işlenebilir. High cardinality sayesinde dağılım iyi olabilir. Sipariş olmayan event tipleri için farklı domain key gerekebilir.

Account ID

Account ID finansal bakiye gibi hesap bazlı sıranın önemli olduğu durumlarda kullanışlıdır. Aynı hesap event'leri aynı partition'a gider. Tek bir yüksek trafikli hesap hot partition oluşturabilir. Business consistency ihtiyacı bu maliyeti haklı çıkarabilir. Alternatif aggregation modelleri ayrıca değerlendirilebilir.

Tenant ID

Tenant ID tenant bazında ordering gerektiğinde kullanılabilir. Az sayıda büyük tenant varsa dağılım kötüleşebilir. Bir tenant diğerlerini etkileyebilir. Noisy Neighbor riski oluşabilir. Tenant + entity gibi birleşik key bazı sistemlerde daha dengeli sonuç verebilir.

High-Cardinality Key

High-cardinality key partition'lar arasında daha dengeli dağılım sağlayabilir. Çok sayıda farklı key değeri olması avantajdır. Ancak yalnızca dağılım için business ordering requirement bozulmamalıdır. Hash algoritması key'i partition'a map eder. Partition sayısı değiştiğinde dağılım davranışı yeniden değerlendirilmelidir.

Hot Partition Problemi

Hot Partition belirli partition'ın diğerlerinden çok daha fazla trafik almasıdır. Tek tenant veya popüler entity bunu tetikleyebilir. Consumer kapasitesi o partition için sınırda kalır. Lag yalnızca belirli partition'da büyür. Key tasarımı ve traffic distribution metrikleri birlikte incelenmelidir.

Out-of-Order Event Nasıl Yönetilir?

Out-of-order event, event'lerin beklenen business sırasından farklı ulaşmasıdır. Network retry, farklı partition veya paralel producer bu durumu oluşturabilir. Sequence number veya aggregate version eski event'i tespit etmeye yardımcı olur. Bazı consumer'lar eski event'i ignore edebilir, bazıları ise buffer içinde bekletebilir. Seçim business state'in nasıl hesaplandığına göre yapılmalıdır.

Sequence Number

Sequence Number aggregate event'lerine artan sıra numarası verir. Consumer son işlenen değeri saklar. Daha küçük numara geldiğinde eski event olarak tanıyabilir. Eksik sıra varsa buffer veya reconciliation çalışabilir. Sequence producer tarafında güvenilir şekilde üretilmelidir.

Aggregate Version

Aggregate Version entity state değiştikçe artan version değeridir. Event bu version bilgisini taşıyabilir. Consumer yalnızca beklenen sonraki version'ı kabul edebilir. Gap oluşursa event eksikliği fark edilir. Bu yaklaşım ordering sorunlarını görünür hâle getirir.

Event Timestamp

Event Timestamp olayın ne zaman gerçekleştiğini gösterir. Ordering için yardımcı sinyal olabilir. Distributed clock farklılıkları nedeniyle tek başına güvenli sıra garantisi değildir. Aynı millisecond içinde birden fazla event olabilir. Sequence veya version daha güçlü seçenek olabilir.

Eski Event'i Ignore Etmek

Consumer current version'dan eski event'i görürse ignore edebilir. Bu yaklaşım state snapshot güncellemelerinde işe yarar. Ancak event side effect taşıyorsa dikkat gerekir. Ignore kararı business semantics'e dayanmalıdır. Audit için event'in atlandığı kaydedilebilir.

Buffer ve Reordering

Consumer kısa süreli buffer tutarak event'lerin tamamlanmasını bekleyebilir. Eksik sequence geldiğinde önceki event için belirli süre beklenir. Buffer memory ve latency maliyeti getirir. Eksik mesaj hiç gelmezse fallback gerekir. Bu yöntem yalnızca ordering gerçekten önemliyse kullanılmalıdır.

Compensation

Yanlış sırada işlenen event geri alınamayabilir. Compensation yeni bir business action ile etkisini düzeltir. Örneğin yanlış rezervasyon geri bırakılabilir. Compensation her zaman tam rollback değildir. Saga tasarımında bu gerçek açık biçimde kabul edilir.

Event Time ve Processing Time

Event Time olayın gerçek dünyada veya source sistemde gerçekleştiği zamanı ifade eder. Processing Time ise consumer'ın olayı işlediği zamandır. Bu iki değer özellikle analytics ve stream processing sistemlerinde farklı olabilir. Network gecikmesi, broker backlog veya consumer downtime late-arriving event oluşturabilir. Sistem hesaplamalarının hangi zamanı baz aldığı açık biçimde tanımlanmalıdır.

Event Ne Zaman Gerçekleşti?

Event time producer'ın business olayını oluşturduğu zamanı temsil eder. Timestamp event metadata içinde taşınabilir. Source clock güvenilir olmalıdır. Mobil veya edge cihazlarda clock sapmaları görülebilir. Kritik ordering için timestamp tek başına yeterli değildir.

Event Ne Zaman İşlendi?

Processing time consumer'ın event'i ele aldığı zamandır. Broker lag bu değeri event time'dan uzaklaştırabilir. Monitoring için iki zaman arasındaki fark değerlidir. End-to-end latency bu fark üzerinden ölçülebilir. Incident sırasında backlog etkisini anlamaya yardımcı olur.

Late-Arriving Event

Late-arriving event beklenenden geç ulaşan olaydır. Consumer restart veya network kesintisi buna neden olabilir. Analytics window hesapları bundan etkilenebilir. Watermark benzeri yöntemler kullanılabilir. Business state consumer'larında version kontrolü daha uygun olabilir.

Distributed Clock Problemi

Dağıtık makinelerin saatleri tam olarak aynı olmayabilir. NTP sapmaları timestamp sıralamasını etkileyebilir. Farklı bölgeler arasında gecikme de eklenir. Bu nedenle timestamp'i global ordering garantisi gibi kullanmak risklidir. Sequence veya logical version daha güvenli olabilir.

Retry Stratejileri

Retry geçici hataların otomatik olarak yeniden denenmesini sağlar. Fakat her hata tekrar denenmemelidir. Network timeout veya 503 gibi geçici durumlarda exponential backoff ve jitter etkili olabilir. Invalid payload veya business validation hatasında tekrar deneme çoğu zaman fayda sağlamaz. Production retry politikası hata sınıflandırması, maksimum deneme ve DLQ davranışıyla birlikte tanımlanmalıdır.

Retryable Error

Retryable Error kısa süre sonra düzelme ihtimali olan hatadır. Network timeout buna örnektir. Geçici database connection problemi de retry edilebilir. Consumer hemen sınırsız deneme yapmamalıdır. Backoff downstream sistemin toparlanmasına zaman verir.

Non-Retryable Error

Non-Retryable Error aynı input ile tekrarlandığında düzelmeyecek hatadır. Invalid schema buna örnektir. Business validation failure da çoğu zaman retry gerektirmez. Mesaj DLQ'ya yönlendirilebilir. Operasyon ekibi hatanın kaynağını inceleyebilir.

Immediate Retry

Immediate Retry hata sonrası beklemeden yeniden deneme yapar. Çok kısa transient network glitch durumunda işe yarayabilir. Downstream gerçekten unavailable ise yükü artırır. Deneme sayısı düşük tutulmalıdır. Ardından backoff stratejisine geçmek daha güvenlidir.

Exponential Backoff

Exponential Backoff her denemede bekleme süresini artırır. Bir saniye, iki saniye, dört saniye gibi ilerleyebilir. Downstream sisteme iyileşme süresi verir. Sonsuz büyüme yerine maksimum delay belirlenmelidir. Retry budget ile birlikte kullanılması faydalıdır.

Jitter

Jitter retry zamanına rastgele sapma ekler. Tüm consumer'ların aynı anda yeniden deneme yapmasını önler. Thundering Herd etkisini azaltır. Özellikle çok sayıda instance olan sistemlerde önemlidir. Backoff tek başına senkron retry dalgasını engellemeyebilir.

Maximum Attempts

Maximum Attempts bir mesaj için en fazla kaç deneme yapılacağını sınırlar. Sonsuz retry poison message nedeniyle queue'yu tıkayabilir. Limit aşıldığında DLQ kullanılabilir. Kritik operasyonlar için manual intervention başlatılabilir. Deneme sayısı hata tipine göre farklılaştırılabilir.

Her Hata Retry Edilmeli mi?

Her hata retry edilmemelidir. Geçici altyapı sorunları tekrar denendiğinde düzelebilir. Invalid payload veya schema uyumsuzluğu aynı mesajla tekrarlandığında değişmeyecektir. Business validation hataları da çoğu zaman insan veya veri düzeltmesi gerektirir. Hata sınıflandırması yapılmadan genel retry uygulamak retry storm ve gereksiz broker trafiği üretir.

Network Timeout

Network Timeout geçici olabilir. Kontrollü retry çoğu zaman uygundur. External operation'ın aslında başarıyla tamamlanmış olma ihtimali unutulmamalıdır. Bu nedenle idempotency key önemlidir. Timeout sonrası aynı side effect kör biçimde tekrarlanmamalıdır.

Geçici Database Problemi

Connection pool veya kısa süreli failover problemi geçici olabilir. Backoff ile retry fayda sağlayabilir. Database tamamen unavailable ise hızlı retry sistemi daha da zorlayabilir. Circuit breaker veya retry budget kullanılabilir. Health metrikleri durumun süresini anlamaya yardımcı olur.

503 Service Unavailable

503 genellikle downstream servisin geçici olarak hizmet veremediğini gösterir. Retry uygulanabilir. Retry-After bilgisi varsa dikkate alınmalıdır. Jitter ile istemcilerin aynı anda dönmesi önlenebilir. Uzun kesintide circuit breaker faydalı olur.

Invalid Payload

Invalid Payload kendiliğinden düzelmeyecek hatadır. Aynı mesajı tekrar göndermek sonucu değiştirmez. Mesaj DLQ'ya taşınabilir. Error details ve event metadata saklanmalıdır. Producer contract hatası varsa source ekip bilgilendirilmelidir.

Schema Hatası

Schema mismatch consumer'ın mesajı deserialize edememesine neden olabilir. Retry genellikle fayda sağlamaz. Schema Registry compatibility gate bu hatayı deployment öncesinde engelleyebilir. Mesaj DLQ'ya alınabilir. Breaking change kaynağı hızla araştırılmalıdır.

Business Validation Hatası

Business validation failure teknik hata değildir. Örneğin kapatılmış hesaba işlem yapılamayabilir. Aynı event tekrar denendiğinde sonuç değişmeyebilir. Compensation veya manual review gerekebilir. Hata tipi observability içinde teknik failure'dan ayrı gösterilmelidir.

Retry Storm Nedir?

Retry Storm downstream sistem çöktüğünde çok sayıda consumer'ın aynı anda ve sürekli retry yapmasıdır. Bu trafik iyileşmeye çalışan servisi daha fazla baskı altında bırakır. Exponential backoff tek başına yeterli olmayabilir, jitter da kullanılmalıdır. Circuit breaker ve retry budget isteği sınırlandırabilir. Production incident'lerinde retry davranışının sistem kapasitesini nasıl etkilediği önceden load test ile görülmelidir.

Downstream Service Çöktüğünde Tüm Consumer'ların Retry Yapması

Bir downstream servis kapandığında tüm consumer instance'ları hata almaya başlar. Her instance anında retry yaparsa trafik katlanır. Bu durum servisin yeniden ayağa kalkmasını zorlaştırır. Queue lag ayrıca büyür. Kontrollü backoff ve circuit breaker gerekir.

Thundering Herd

Thundering Herd çok sayıda istemcinin aynı anda aynı kaynağa saldırmasını ifade eder. Sabit retry interval bunu tetikleyebilir. Tüm consumer'lar üç saniye sonra birlikte tekrar deneyebilir. Jitter retry zamanlarını dağıtır. Böylece peak yük azaltılabilir.

Backoff

Backoff denemeler arasındaki süreyi artırır. Downstream sisteme toparlanma zamanı verir. Consumer CPU kullanımını da azaltır. Maksimum delay belirlenmelidir. Recovery sonrasında backlog kontrollü biçimde eritilmelidir.

Jitter

Jitter backoff süresine random gecikme ekler. Retry trafiğini zamana yayar. Büyük consumer fleet'lerinde etkisi belirgindir. Aynı instance restart olduğunda da faydalı olabilir. Algorithm seçimi sistem yüküne göre test edilmelidir.

Circuit Breaker

Circuit Breaker art arda başarısız çağrılarda downstream isteğini geçici durdurur. Böylece sürekli timeout beklenmez. Belirli süre sonra kontrollü probe yapılabilir. Mesajlar broker'da bekleyebilir. Circuit state metrik olarak izlenmelidir.

Retry Budget

Retry Budget toplam retry trafiğine sınır koyar. Normal request sayısının belirli oranını aşmaması hedeflenebilir. Incident sırasında sistemin kendi kendine yük üretmesini önler. Kritik ve düşük öncelikli akışlara farklı budget uygulanabilir. Bu yaklaşım yüksek trafikli backend sistemlerinde faydalıdır.

Dead Letter Queue (DLQ/DLT) Nedir?

Dead Letter Queue veya Dead Letter Topic belirli sayıda retry sonrasında işlenemeyen mesajların taşındığı ayrı alandır. Poison message, invalid payload veya kalıcı consumer hatası bunun tipik nedenleridir. DLQ mesajı kaybetmek yerine inceleme için saklar. Original topic, error details ve attempt count gibi metadata operasyon ekibine yardımcı olur. DLQ kurmak tek başına yeterli değildir, mesajların nasıl inceleneceği ve tekrar işleneceği de süreç olarak tanımlanmalıdır.

Poison Message

Poison Message consumer'ın her denemesinde hata veren mesajdır. Invalid data veya beklenmeyen schema buna neden olabilir. Sonsuz retry consumer kapasitesini tüketir. Belirli attempt sonrasında DLQ'ya taşınmalıdır. Root cause ayrıca producer tarafında düzeltilmelidir.

Retry Exhausted

Retry Exhausted belirlenen maksimum deneme sayısının aşıldığını ifade eder. Mesaj artık otomatik normal retry akışında tutulmaz. DLQ'ya gönderilebilir. Alert oluşturulabilir. Operasyon sahibi gerekli remediation adımını başlatır.

Invalid Message

Invalid Message contract veya business doğrulamasını geçmeyen mesajdır. Deserialize bile edilemeyebilir. Aynı payload ile retry çoğu zaman faydasızdır. Hata ayrıntısı DLQ metadata içinde tutulmalıdır. Producer validation bu hataların sayısını azaltabilir.

Dead Letter Metadata

Dead Letter Metadata mesajın neden başarısız olduğunu anlamayı kolaylaştırır. Error type ve exception bilgisi eklenebilir. Original destination saklanmalıdır. Attempt count incident analizi için değerlidir. Trace ID dağıtık akışın diğer adımlarıyla bağlantı kurar.

Original Topic

Original Topic mesajın ilk yayınlandığı yeri gösterir. Replay sırasında doğru destination'ın belirlenmesini sağlar. Aynı DLQ birden fazla source kullanıyorsa özellikle önemlidir. Topic version bilgisi de yararlı olabilir. Yanlış destination'a replay riskini azaltır.

Error Details

Error Details hatanın sınıfını ve kısa açıklamasını içerebilir. Stack trace tamamen taşınmak zorunda değildir. Hassas veri loglanmamalıdır. Error code otomatik sınıflandırmayı kolaylaştırır. Operasyon tooling bu alanları filtre olarak kullanabilir.

Attempt Count

Attempt Count mesajın kaç kez denendiğini gösterir. Retry policy davranışını doğrulamaya yardımcı olur. Beklenenden yüksek sayı configuration hatasını gösterebilir. Replay sonrası yeni sayaç stratejisi tanımlanmalıdır. Eski ve yeni attempt bilgileri audit için ayrılabilir.

DLQ Tasarımında Neler Saklanmalı?

İyi DLQ tasarımı yalnızca payload saklamakla sınırlı değildir. Event ID, source topic, consumer adı ve retry count olayın bağlamını oluşturur. Exception bilgisi hatanın nedenini açıklamaya yardımcı olur. First ve last failure time incident süresini gösterir. Trace ID kullanılması mesajın distributed trace içindeki diğer işlemlerle eşleştirilmesini kolaylaştırır.

Original Payload

Original Payload düzeltme ve replay için gerekli olabilir. Ancak hassas veri içerme ihtimali değerlendirilmelidir. Encryption veya masking uygulanabilir. Çok büyük payload storage maliyeti oluşturur. Retention policy veri sınıfına göre belirlenmelidir.

Event ID

Event ID mesajı diğer log ve trace kayıtlarıyla ilişkilendirir. Replay sırasında aynı ID korunmalıdır. Duplicate detection bu değeri kullanabilir. DLQ tooling event ID üzerinden arama yapmalıdır. ID formatı kurum genelinde standartlaştırılabilir.

Topic / Queue

Original topic veya queue bilgisi mesajın kaynağını gösterir. Replay hedefi bunun üzerinden seçilebilir. Environment bilgisi de yanlış ortama publish riskini azaltır. Destination adı teknik operasyon için önemlidir. Naming convention anlaşılır olmalıdır.

Consumer

Hangi consumer'ın hata verdiği kaydedilmelidir. Aynı event farklı consumer'larda farklı sonuç verebilir. Consumer version bilgisi de değerlidir. Deployment sonrası artan DLQ oranı bu sayede ilişkilendirilebilir. Owner bilgisinin catalog ile bağlantısı kurulabilir.

Exception

Exception type hatayı sınıflandırmaya yardımcı olur. Tam stack trace her zaman gerekli değildir. Error message kişisel veri içermemelidir. Standard error code otomasyon için faydalıdır. Retryable ve non-retryable ayrımı da kaydedilebilir.

Retry Count

Retry Count mesajın kaç deneme sonunda DLQ'ya gittiğini gösterir. Beklenen policy ile karşılaştırılabilir. Çok düşük count yanlış configuration işareti olabilir. Çok yüksek count resource tüketimine neden olabilir. Dashboard üzerinde distribution olarak izlenebilir.

First/Last Failure Time

First Failure Time problemin ilk görüldüğü anı gösterir. Last Failure Time son deneme zamanını kaydeder. İki değer incident süresini anlamaya yardımcı olur. SLA ve remediation takibi için faydalıdır. Clock standardı UTC olarak tutulabilir.

Trace ID

Trace ID mesajı distributed trace ile eşleştirir. Upstream HTTP request'e kadar gidilebilir. Producer ve consumer span'ları birlikte görülebilir. Incident çözüm süresi kısalır. Trace context event metadata standardının parçası olmalıdır.

DLQ'ya Düşen Mesajlarla Ne Yapılmalı?

DLQ mesajları düzenli olarak işletilmesi gereken operasyon verisidir. İlk adım alert ve investigation sürecidir. Hatanın payload, schema, consumer code veya downstream dependency kaynaklı olup olmadığı belirlenir. Gerekirse payload correction ve güvenli replay yapılır. İş açısından artık anlam taşımayan mesajlar audit izi bırakılarak discard edilebilir.

Alert

DLQ'ya yeni mesaj geldiğinde uygun eşiklerde alert üretilebilir. Her tekil mesaj için paging gerekmez. Kritik event type'larda daha hassas threshold kullanılabilir. Alert owner bilgisi net olmalıdır. Gürültülü alarm sistemi gerçek incident'lerin gözden kaçmasına neden olur.

Investigation

Investigation event metadata ve error details ile başlar. Consumer logs ve traces incelenir. Aynı event type'ta toplu hata olup olmadığı kontrol edilir. Son deployment değişiklikleri gözden geçirilir. Root cause bulunmadan kör replay yapılmamalıdır.

Payload Correction

Bazı durumlarda payload yanlış veya eksik olabilir. Operasyon aracı kontrollü düzeltme imkânı sunabilir. Orijinal mesaj audit için saklanmalıdır. Düzeltilen payload yeni version olarak işaretlenebilir. Manual change yetkilendirme ve kayıt altında tutulmalıdır.

Retry

Geçici sorun düzeldiyse DLQ mesajı tekrar denenebilir. Aynı failure tekrarlanıyorsa mesaj yeniden DLQ'ya dönebilir. Retry sayacı ayrı tutulabilir. Toplu retry downstream sisteme yük bindirmemelidir. Rate limit ile kontrollü yeniden işleme yapılabilir.

Replay

Replay bir veya daha fazla DLQ mesajını tekrar normal akışa sokabilir. Event ID korunmalıdır. Side effect safety doğrulanmalıdır. Gerekirse özel replay topic kullanılabilir. Replay sonucunun başarı oranı ayrıca izlenmelidir.

Discard

Bazı mesajlar business açısından artık geçersiz olabilir. Bu durumda kontrollü discard yapılabilir. Karar gerekçesi audit trail içine yazılmalıdır. Kritik finansal event'ler için ek onay gerekebilir. Otomatik silme politikası dikkatle sınırlandırılmalıdır.

Audit Trail

DLQ mesajına yapılan her işlem kayıt altına alınmalıdır. Kim retry yaptı bilgisi tutulabilir. Ne zaman payload değiştirildiği izlenebilir. Son durum başarılı veya discard olarak işaretlenebilir. Audit trail compliance ve incident review için değerlidir.

DLQ'nun Mesaj Mezarlığına Dönüşmesini Önlemek

DLQ oluşturup hiç takip etmemek production sistemlerde sık görülen anti-pattern'lerden biridir. Her DLQ için açık bir owner bulunmalıdır. Retention ve alert threshold değerleri belirlenmelidir. Remediation SLA mesajların ne kadar süre içinde inceleneceğini netleştirir. Replay tooling ve düzenli review süreci DLQ'yu gerçekten işletilebilir bir recovery mekanizmasına dönüştürür.

DLQ Owner

Her DLQ belirli servis veya ekip tarafından sahiplenilmelidir. Owner bilgisi event catalog içinde tutulabilir. Alert doğrudan doğru ekibe yönlendirilir. Sahipsiz DLQ mesajları zamanla unutulur. Ownership production readiness kontrolünde doğrulanmalıdır.

Retention

DLQ mesajlarının ne kadar süre tutulacağı belirlenmelidir. Çok kısa retention investigation fırsatını azaltır. Çok uzun retention storage ve privacy maliyeti getirir. Event criticality kararı etkiler. KVKK ve GDPR gibi silme gereksinimleri hesaba katılmalıdır.

Alert Threshold

Alert Threshold normal hata oranından ayrışacak şekilde seçilmelidir. Tek mesaj her zaman alarm gerektirmeyebilir. Oran bazlı threshold daha anlamlı olabilir. Kritik ödeme event'i için sıfır tolerans tercih edilebilir. Threshold düzenli olarak production verisine göre gözden geçirilmelidir.

Remediation SLA

Remediation SLA DLQ mesajının ne kadar sürede inceleneceğini belirler. Event türüne göre farklı SLA kullanılabilir. Finansal event daha hızlı ele alınabilir. Düşük öncelikli analitik event daha uzun bekleyebilir. Dashboard SLA ihlallerini görünür hâle getirmelidir.

Replay Tooling

Operasyon ekibi güvenli replay için özel araca ihtiyaç duyar. Event seçimi filtrelenebilir olmalıdır. Dry-run veya preview özelliği faydalıdır. Rate limiting toplu replay yükünü kontrol eder. Yetkilendirme kritik mesajların yanlışlıkla tekrar çalıştırılmasını önler.

Regular Review

DLQ içerikleri belirli aralıklarla gözden geçirilmelidir. Tekrarlayan hata sınıfları product backlog'a alınabilir. Producer contract sorunları bu sayede ortaya çıkar. Consumer resilience iyileştirilebilir. Review toplantısı yalnızca sayıya değil root cause trendlerine odaklanmalıdır.

Backpressure Nedir?

Backpressure producer'ın consumer'dan daha hızlı veri üretmesi durumunda sistemde oluşan baskıdır. Queue depth veya consumer lag zamanla büyüyebilir. Broker disk ve memory kullanımı artabilir. Downstream sistemler saturation noktasına ulaşabilir. Backpressure yönetimi consumer scaling, rate limiting, batching ve gerektiğinde load shedding gibi tekniklerin birlikte kullanılmasını gerektirir.

Producer Consumer'dan Hızlıysa Ne Olur?

Producer saniyede consumer'ın işleyebileceğinden fazla event yayınlayabilir. İlk başta broker farkı tamponlar. Zamanla backlog büyür. Event latency artar. Süreklilik gösteriyorsa kapasite veya business throttling çözümü gerekir.

Queue Growth

Queue Growth birikmiş mesaj sayısının artmasıdır. Kısa süreli peak sonrası azalması normal olabilir. Sürekli artış tehlikelidir. Disk limiti ve retention etkilenebilir. Dashboard growth rate göstermelidir.

Consumer Lag

Consumer Lag producer'ın son offset'i ile consumer'ın işlediği offset arasındaki farktır. Kafka sistemlerinde kritik metriktir. Tek başına mesaj sayısı yeterli olmayabilir. Time lag daha iş anlamlı olabilir. Lag trendi kapasite planında kullanılmalıdır.

Disk/Memory Baskısı

Backlog broker storage tüketimini artırır. RabbitMQ queue memory ve disk davranışı etkilenebilir. Kafka retention içinde daha fazla segment birikir. Disk doluluğu broker health'i tehdit eder. Capacity alarmı önceden devreye girmelidir.

Downstream Saturation

Consumer hızlı çalışmaya çalışırken downstream database'i aşırı yükleyebilir. Connection pool dolabilir. External API rate limit'e takılabilir. Daha fazla consumer eklemek durumu kötüleştirebilir. Sistem en yavaş dependency kapasitesine göre dengelenmelidir.

Backpressure Nasıl Yönetilir?

Backpressure yönetimi yalnızca daha fazla consumer instance açmak değildir. Consumer scaling, downstream kapasitesi yeterliyse işe yarar. Rate limiting producer veya consumer hızını kontrollü tutabilir. Prefetch ve batching throughput davranışını değiştirir. Aşırı yük durumlarında düşük öncelikli işlerin load shedding ile ertelenmesi veya reddedilmesi gerekebilir.

Consumer Scaling

Consumer instance sayısını artırmak paralel processing kapasitesi sağlar. Kafka'da partition sayısı üst sınırdır. RabbitMQ worker sayısı prefetch ile birlikte değerlendirilir. Downstream database kapasitesi kontrol edilmelidir. Autoscaling lag metriğine bağlanabilir.

Rate Limiting

Rate Limiting işleme hızını kontrollü sınırlar. External API quota'larını korur. Database saturation riskini azaltır. Tenant bazlı limit uygulanabilir. Limit aşımı mesajların broker'da beklemesine neden olabilir.

Prefetch

Prefetch consumer'ın aynı anda kaç mesaj alacağını belirleyebilir. Çok yüksek değer bir consumer'ın fazla mesaj tutmasına neden olur. Çok düşük değer throughput'u azaltabilir. Processing süresine göre test edilmelidir. RabbitMQ için kritik tuning parametrelerinden biridir.

Batching

Batching birden fazla event'i birlikte işlemeyi sağlar. Database round-trip sayısını azaltabilir. Throughput artabilir. Buna karşılık latency ve failure granularity etkilenir. Batch içinde tek hata olduğunda strateji açık olmalıdır.

Flow Control

Flow Control producer veya consumer hızını sistem durumuna göre düzenler. Broker bazı durumlarda producer'ı yavaşlatabilir. Uygulama queue depth üzerinden throttle uygulayabilir. Feedback loop kararlı tasarlanmalıdır. Ani oscillation istenmeyen yük dalgaları oluşturabilir.

Load Shedding

Load Shedding sistem kapasitesi aşıldığında düşük öncelikli işi bırakmayı veya ertelemeyi ifade eder. Her business event için uygun değildir. Telemetri gibi kayıp toleranslı akışlarda kullanılabilir. Kritik işlemler korunmalıdır. Öncelik sınıfları baştan tanımlanmalıdır.

Kafka Consumer Lag Nedir?

Kafka Consumer Lag consumer'ın producer tarafından yazılmış son event'in ne kadar gerisinde olduğunu gösterir. Latest Offset ile Consumer Offset arasındaki fark mesaj sayısı bazlı lag değerini verir. Lag kısa trafik sıçramalarında artıp sonra düşebilir. Sürekli artması consumer throughput'unun producer rate'in altında kaldığını gösterebilir. Lag tek başına hata değildir, business toleransına ve event zamanına göre yorumlanmalıdır.

Latest Offset

Latest Offset partition'da yazılmış en son mesaj konumunu temsil eder. Producer trafiği arttıkça bu değer ilerler. Consumer current offset ile karşılaştırılır. Partition bazında takip edilmelidir. Tek hot partition toplam ortalamada gizlenebilir.

Consumer Offset

Consumer Offset consumer'ın commit ettiği ilerleme konumudur. Processing tamamlanmadan commit edilmesi message loss riskini artırabilir. Commit gecikirse duplicate delivery görülebilir. Manual commit daha fazla kontrol sunar. Strategy processing semantics ile uyumlu olmalıdır.

Lag

Lag latest offset ile consumer offset arasındaki farktır. Mesaj sayısı olarak ifade edilebilir. Farklı message processing süreleri nedeniyle aynı lag her zaman aynı risk değildir. Time lag daha açıklayıcı olabilir. Dashboard ikisini birlikte gösterebilir.

Lag'in Sürekli Artması

Sürekli artan lag consumer'ın yetişemediğini gösterir. Processing latency yükselmiş olabilir. Downstream service yavaşlamış olabilir. Partition dağılımı dengesiz olabilir. Root cause bulunduktan sonra scaling veya optimizasyon yapılmalıdır.

Lag = Hata mı?

Her lag hata değildir. Batch consumer belirli aralıklarla geride kalabilir. Trafik peak sonrası lag kısa sürede kapanabilir. Business SLO belirlenen gecikme sınırını tanımlar. Alarm sabit sayı yerine süre ve trend bilgisiyle tasarlanmalıdır.

Consumer Lag Alarmı Nasıl Tasarlanmalı?

Consumer lag alarmı yalnızca mesaj sayısına dayanırsa yanıltıcı olabilir. Trafik hacmi yüksek bir sistemde on bin mesaj birkaç saniyelik gecikme anlamına gelebilir. Düşük trafikli sistemde aynı sayı saatler sürebilir. Time lag, consumer throughput ve lag growth rate birlikte değerlendirilmelidir. Alarm business SLO ile ilişkilendirildiğinde ekip için daha anlamlı olur.

Mesaj Sayısı Bazlı Lag

Message count lag kolay ölçülen bir metriktir. Partition bazında takip edilmelidir. Trafik hacmine göre normal değer değişebilir. Sabit threshold yanlış alarm üretebilir. Historical baseline yardımcı olabilir.

Time Lag

Time Lag en eski işlenmemiş event'in ne kadar süredir beklediğini gösterir. Business anlamı daha açıktır. Kullanıcı bildirimlerinin beş dakika gecikmesi doğrudan görülebilir. Event timestamp güvenilir olmalıdır. Dashboard p95 time lag gösterebilir.

Traffic Volume

Traffic Volume alarm yorumunda bağlam sağlar. Producer rate arttığında lag geçici büyüyebilir. Aynı zamanda consumer rate de izlenmelidir. Peak dönemler için farklı threshold gerekebilir. Capacity planning bu verilerle desteklenir.

Consumer Throughput

Consumer Throughput saniyede işlenen event sayısını gösterir. Producer rate ile karşılaştırılır. Uzun süre daha düşük kalırsa backlog büyür. Deployment sonrası düşüş regression gösterebilir. Processing latency metriğiyle birlikte yorumlanmalıdır.

Lag Growth Rate

Lag Growth Rate backlog'un ne hızla büyüdüğünü gösterir. Mevcut lag küçük olsa bile hızlı artış erken alarm olabilir. Negatif rate backlog'un kapandığını gösterir. Bu metrik autoscaling için kullanılabilir. Ani spike ile sürekli trend ayrılmalıdır.

Kafka Consumer Offset Yönetimi

Offset yönetimi Kafka consumer güvenilirliğinin merkezindedir. Auto commit kullanımı kolaydır ancak iş tamamlanmadan offset commit etme riski vardır. Manual commit processing sonucuyla daha iyi senkronize edilebilir. İşlemden sonra commit edilen model consumer crash durumunda redelivery üretebilir. Bu nedenle duplicate event normal kabul edilmeli ve consumer idempotent tasarlanmalıdır.

Auto Commit

Auto Commit belirli aralıklarla offset'i otomatik kaydeder. Uygulama kodunu sadeleştirir. Fakat processing tamamlanmadan offset ilerleyebilir. Crash durumunda mesaj tekrar okunmayabilir. Kritik business consumer'larında dikkatle değerlendirilmelidir.

Manual Commit

Manual Commit offset zamanlamasını uygulamaya bırakır. Business operation tamamlandıktan sonra commit yapılabilir. Bu yaklaşım at-least-once processing için daha uygundur. Commit failure duplicate delivery oluşturabilir. Consumer idempotency gereklidir.

İşlemden Önce Commit Riski

Offset processing öncesinde commit edilirse broker mesajı tamamlanmış sanabilir. Consumer daha sonra crash olabilir. Business operation hiç gerçekleşmemiş olur. Mesaj tekrar gelmez. Bu kritik message loss senaryosudur.

İşlemden Sonra Commit

Processing tamamlandıktan sonra offset commit edilir. Crash commit öncesinde olursa event tekrar gelir. Bu duplicate ihtimalidir. Idempotent consumer tekrar işlemeyi güvenli karşılar. Çoğu business akışında veri kaybından daha kabul edilebilir bir trade-off'tur.

Crash Sonrası Redelivery

Consumer crash olduğunda commit edilmemiş offset yeniden işlenebilir. Yeni consumer partition'ı devralır. Aynı event tekrar alınabilir. Processing gerçekten bitmiş olabilir. Event ID deduplication bu yüzden kritik önemdedir.

RabbitMQ Acknowledgement Yönetimi

RabbitMQ acknowledgement consumer'ın mesajı başarıyla işlediğini broker'a bildirme mekanizmasıdır. Auto Ack yüksek hız sağlasa da failure durumunda message loss riskini artırabilir. Manual Ack iş tamamlandıktan sonra gönderildiğinde daha güvenilir davranış sağlar. Nack ve requeue hatalı mesajın yeniden kuyruğa alınmasını kontrol eder. Prefetch ve consumer crash davranışı acknowledgement stratejisiyle birlikte test edilmelidir.

Auto Ack

Auto Ack mesaj consumer'a ulaştığında başarılı kabul edebilir. İşlem henüz tamamlanmamış olabilir. Consumer crash olursa mesaj yeniden teslim edilmeyebilir. Kritik işlerde bu risk yüksektir. Düşük kritik throughput akışlarında tercih edilebilir.

Manual Ack

Manual Ack consumer'ın başarı sonrasında açıkça onay göndermesidir. Business transaction bittikten sonra ack yapılabilir. Crash öncesinde ack gitmezse mesaj redelivery olur. Duplicate ihtimali doğar. Idempotency ile birlikte güçlü bir model oluşturur.

Nack

Nack mesajın başarısız işlendiğini broker'a bildirir. Requeue seçeneğiyle mesaj yeniden kuyruğa alınabilir. Kalıcı hata için requeue false kullanılabilir. Dead letter exchange devreye girebilir. Sonsuz nack-requeue döngüsünden kaçınılmalıdır.

Requeue

Requeue mesajı tekrar queue içine koyar. Geçici hatalarda faydalıdır. Aynı poison message sürekli dönüyorsa consumer kapasitesini tüketir. Retry count broker header veya uygulama metadata ile izlenebilir. Belirli limit sonrası DLQ kullanılmalıdır.

Prefetch

Prefetch consumer'ın ack edilmemiş kaç mesaj tutabileceğini sınırlar. Yüksek prefetch throughput'u artırabilir. Uzun işlerde mesajlar tek consumer'da yığılabilir. Low prefetch daha dengeli dağılım sağlayabilir. Değer workload ile test edilmelidir.

Consumer Crash

Consumer crash olduğunda unacked mesajlar başka consumer'a teslim edilebilir. Bu durum güvenilirlik sağlar. Aynı business operation daha önce tamamlanmış olabilir. Duplicate side effect riski vardır. Idempotent processing ve doğru ack sırası temel çözümdür.

Event Schema Nedir?

Event Schema event payload ve metadata yapısını tanımlayan contract'tır. Field name, field type ve required veya optional davranışları schema içinde belirlenebilir. Schema version değişikliklerin izlenmesini sağlar. Producer ve consumer aynı sözleşme üzerinden anlaşır. Event schema uzun ömürlü entegrasyon API'si gibi yönetildiğinde servislerin bağımsız geliştirilmesi daha güvenli olur.

Event Contract

Event Contract producer ile consumer arasındaki veri anlaşmasıdır. Hangi alanların ne anlama geldiğini açıklar. Yalnızca JSON örneği contract için yeterli değildir. Semantik anlam da dokümante edilmelidir. Owner ve version bilgisi bulunmalıdır.

Field Name

Field Name domain anlamını açıkça yansıtmalıdır. Teknik internal property isimlerinden kaçınmak faydalıdır. İsim değişikliği breaking change olabilir. Consumer'ların kullanım durumu bilinmelidir. Naming convention kurum genelinde standartlaştırılabilir.

Field Type

Field Type verinin biçimini belirler. String'i integer'a çevirmek eski consumer'ları bozabilir. Timestamp formatı açık olmalıdır. Para değerleri için decimal ve currency ayrımı düşünülmelidir. Type değişiklikleri compatibility kontrolünden geçmelidir.

Required / Optional

Required field consumer'ın alanın her event'te var olduğunu varsaymasına neden olur. Sonradan required alan eklemek eski event'lerle sorun yaratabilir. Optional field daha esnek evolution sağlar. Default value davranışı tanımlanmalıdır. Contract business anlamını kaybetmeyecek kadar açık kalmalıdır.

Metadata

Metadata event'in transport ve tracing bağlamını taşır. Event ID, timestamp ve source temel alanlardır. Correlation ID business flow takibini kolaylaştırır. Schema version consumer parsing davranışına yardımcı olur. Tenant ID yalnızca gerçek multi-tenant ihtiyaç varsa eklenmelidir.

Schema Version

Schema Version event contract'ın hangi sürümde olduğunu gösterir. Consumer farklı version'ları destekleyebilir. Registry çoğu durumda version geçmişini tutar. Version numarası tek başına migration stratejisi değildir. Compatibility policy ile birlikte kullanılmalıdır.

Event Serialization Formatları

Event serialization için JSON, Avro, Protocol Buffers ve JSON Schema tabanlı yaklaşımlar kullanılabilir. JSON insan tarafından okunabilir olması nedeniyle geliştirme ve debugging sırasında kolaylık sağlar. Avro ve Protocol Buffers daha kompakt binary formatlar sunabilir. Format seçimi mesaj boyutu, performans, schema governance ve ekip araçlarıyla uyumlu olmalıdır. Hiçbir format schema evolution problemini kendi başına çözmez, compatibility politikası yine gereklidir.

JSON

JSON okunabilir ve yaygın desteklenen formattır. Debug sırasında mesajı gözle incelemek kolaydır. Payload boyutu binary formatlara göre daha büyük olabilir. Type sistemi daha gevşektir. JSON Schema ile contract kontrolü güçlendirilebilir.

Avro

Avro schema odaklı binary serialization sunar. Kafka ekosisteminde sık kullanılır. Payload kompakt olabilir. Schema Registry ile compatibility yönetimi güçlüdür. İnsan tarafından doğrudan okunabilir değildir.

Protocol Buffers

Protocol Buffers güçlü schema ve code generation desteği sağlar. Binary formatı verimlidir. Field number yönetimi önemlidir. Silinen field numaralarının yeniden kullanılmaması gerekir. Farklı dil ekipleri için iyi tooling sunar.

JSON Schema

JSON Schema JSON payload yapısını doğrulamak için kullanılabilir. Field type ve required kuralları tanımlanabilir. CI pipeline içinde validation yapılabilir. Runtime contract hataları azaltılabilir. Compatibility için ek kurallar gerekebilir.

Boyut

Mesaj boyutu broker throughput ve storage maliyetini etkiler. Binary formatlar genellikle daha kompakt olabilir. Compression ayrıca kullanılabilir. Çok büyük payload event broker'a uygun olmayabilir. Object storage reference pattern alternatif sunar.

Performans

Serialization ve deserialization CPU maliyeti oluşturur. Binary formatlar bazı workload'larda daha hızlı olabilir. Gerçek fark payload ve runtime'a bağlıdır. Benchmark kendi event modelleriyle yapılmalıdır. Network ve broker latency çoğu zaman toplam sürede daha büyük pay taşıyabilir.

İnsan Tarafından Okunabilirlik

JSON debugging sırasında kolay okunur. Binary event'ler için tooling gerekir. Production incident'lerinde event viewer kullanmak faydalıdır. Okunabilirlik uğruna hassas payload düz loglanmamalıdır. Observability metadata üzerinden kurulmalıdır.

Schema Registry Nedir?

Schema Registry event schema'larını merkezi olarak saklayan ve version yönetimi sağlayan sistemdir. Producer yayınlamadan önce uygun schema ile validation yapabilir. Consumer hangi contract'ı okuduğunu bilir. Compatibility check breaking change'lerin production'a ulaşmasını engellemeye yardımcı olur. Kurum çapında event governance için Schema Registry güçlü bir teknik kontrol noktasıdır.

Merkezi Schema Catalog

Registry tüm event schema'larını merkezi yerde tutar. Version geçmişi görünür olur. Ekipler mevcut contract'ları keşfedebilir. Duplicate event tasarımları azaltılabilir. Event catalog ile birlikte kullanıldığında governance güçlenir.

Producer Validation

Producer event'i schema kurallarına göre doğrulayabilir. Invalid payload broker'a ulaşmadan engellenir. CI testleri de aynı schema'yı kullanabilir. Runtime error oranı azalır. Validation failure metric olarak izlenebilir.

Consumer Contract

Consumer hangi field'ların mevcut olduğunu schema üzerinden bilir. Generated code kullanılabilir. Version mismatch erken tespit edilir. Contract testleri registry ile entegre olabilir. Consumer'ın optional alanları doğru yönetmesi gerekir.

Schema Version

Her schema değişikliği yeni version oluşturabilir. Registry geçmiş sürümleri saklar. Consumer migration sürecinde farklı version'ları okuyabilir. Version artışı breaking change anlamına gelmek zorunda değildir. Compatibility rule gerçek riski belirler.

Compatibility Check

Compatibility Check yeni schema'nın eski consumer veya producer'larla uyumunu değerlendirir. Backward ve forward modları farklı garantiler sunar. CI pipeline change'i otomatik bloklayabilir. Manuel review semantik anlamı ayrıca kontrol etmelidir. Teknik uyumluluk business uyumluluğun tamamı değildir.

Schema Evolution

Schema Evolution event contract'larının zaman içinde değişmesini güvenli biçimde yönetme sürecidir. Yeni optional field eklemek çoğu zaman uyumlu değişikliktir. Field silmek, required alan eklemek veya type değiştirmek daha yüksek risk taşır. Default value eski mesajların yeni consumer tarafından okunmasını kolaylaştırabilir. Hedef eski consumer'ların deployment zorunluluğu olmadan çalışmaya devam edebilmesidir.

Yeni Field Ekleme

Optional yeni field çoğu zaman güvenli değişikliktir. Eski consumer alanı görmezden gelebilir. Yeni consumer field yoksa default kullanabilir. Required yapmak riski artırır. Compatibility test deployment öncesinde çalışmalıdır.

Field Silme

Field silmek bazı consumer'ları bozabilir. Kimlerin kullandığı event catalog üzerinden kontrol edilmelidir. Önce deprecated olarak işaretlemek daha güvenlidir. Consumer migration tamamlandıktan sonra kaldırılabilir. Uzun ömürlü event history replay gereksinimi unutulmamalıdır.

Type Değiştirme

Type change yüksek riskli schema değişikliğidir. String'den integer'a geçmek parsing hatası oluşturabilir. Yeni field ekleyip eski field'i zamanla kaldırmak daha güvenlidir. V1 ve V2 birlikte desteklenebilir. CI breaking gate bunu otomatik engelleyebilir.

Default Value

Default Value eski event'lerde bulunmayan alan için fallback sağlar. Business anlamı doğru seçilmelidir. Rastgele default veri yanlış state üretmemelidir. Schema formatının default semantiği anlaşılmalıdır. Consumer davranışı test edilmelidir.

Eski Consumer'ların Çalışmaya Devam Etmesi

Schema evolution'ın temel hedeflerinden biri eski consumer'ları kırmamaktır. Producer değişikliği bağımsız deploy edilebilmelidir. Optional alan ve backward compatibility bu konuda yardımcı olur. Consumer usage catalog önemlidir. Breaking migration kontrollü dönem içinde yapılmalıdır.

Schema Compatibility Türleri

Schema compatibility yeni ve eski schema sürümlerinin birlikte çalışabilme kurallarını tanımlar. Backward compatibility yeni consumer'ın eski mesajları okuyabilmesine odaklanır. Forward compatibility eski consumer'ın yeni mesajları okuyabilmesini değerlendirir. Full compatibility iki yönü birlikte hedefler. None modu kontrolü kaldırır ve ancak çok kontrollü ortamlarda tercih edilmelidir.

Backward Compatibility

Backward Compatibility yeni schema ile eski verilerin okunabilmesini hedefler. Replay yoğun sistemlerde önemlidir. Yeni consumer geçmiş event'leri okuyabilmelidir. Optional field eklemek çoğu zaman uyumludur. Type change sorun yaratabilir.

Forward Compatibility

Forward Compatibility eski consumer'ın yeni producer mesajlarını okuyabilmesini hedefler. Rolling deployment sırasında faydalıdır. Eski consumer yeni alanları ignore edebilir. Required semantiği dikkat ister. Schema formatının kuralları bilinmelidir.

Full Compatibility

Full Compatibility backward ve forward gereksinimlerini birlikte karşılar. En güçlü uyumluluk hedefidir. Schema değişiklik alanını sınırlar. Uzun ömürlü entegrasyonlarda faydalıdır. Her domain için gerekli olmayabilir.

None

None compatibility kontrolü uygulanmadığı anlamına gelir. Breaking change kolayca yayınlanabilir. Küçük deneysel sistemlerde geçici olarak kabul edilebilir. Kurumsal event platformunda risklidir. En azından contract test ile ek güvenlik sağlanmalıdır.

Hangisi Ne Zaman Kullanılmalı?

Replay önemliyse backward compatibility güçlü adaydır. Rolling producer-consumer deployment varsa forward davranış da değerlidir. Kurum çapında shared event'lerde full compatibility tercih edilebilir. Hızlı internal stream'lerde daha esnek politika kullanılabilir. Seçim event lifecycle ve consumer bağımsızlığına göre yapılmalıdır.

Event Schema Değişiklikleri CI/CD'de Nasıl Kontrol Edilir?

Schema değişiklikleri yalnızca code review ile yönetilmemelidir. CI pipeline içinde schema lint ve compatibility check otomatik çalıştırılabilir. Producer ve consumer contract testleri breaking değişiklikleri erken yakalar. Schema Registry validation merge veya deployment öncesinde gate olarak kullanılabilir. Bu yaklaşım event contract yönetimini kişisel dikkat yerine tekrar edilebilir mühendislik sürecine dönüştürür.

Schema Lint

Schema Lint naming ve format kurallarını kontrol eder. Yasak alan isimleri tespit edilebilir. Documentation gereksinimi zorunlu tutulabilir. Type convention doğrulanabilir. Review yükü azaltılır.

Compatibility Check

Yeni schema mevcut registry version'ıyla karşılaştırılır. Breaking değişiklik otomatik tespit edilebilir. Pipeline failure merge'i durdurur. Override yetkisi sınırlı olmalıdır. Change gerekçesi audit altında tutulabilir.

Contract Test

Contract Test producer event'inin consumer beklentisiyle uyumunu doğrular. Örnek payload'lar kullanılabilir. Consumer-driven contract yaklaşımı uygulanabilir. Serialization gerçek runtime kütüphanesiyle test edilmelidir. Sadece JSON fixture kontrolü yeterli olmayabilir.

Schema Registry Validation

CI registry API üzerinden schema doğrulaması yapabilir. Yeni version publish edilmeden compatibility test edilir. Environment bazlı registry kullanılabilir. Production registry doğrudan test pipeline tarafından değiştirilmemelidir. Promotion süreci tanımlanmalıdır.

Breaking Change Gate

Breaking Change Gate uyumsuz değişikliği deployment öncesinde engeller. Override gerekiyorsa review ve migration planı istenir. Consumer owner'lar bilgilendirilir. V2 event strategy hazırlanır. Böylece production incident riski azaltılır.

Event Versioning Nasıl Yapılmalı?

Event versioning yalnızca event adına v2 eklemekten ibaret değildir. Mümkün olduğunda schema evolution ile geriye uyumlu değişiklik yapılmalıdır. Gerçek breaking change gerekiyorsa event type veya topic version ayrımı kullanılabilir. V1 ve V2 belirli süre birlikte desteklenebilir. Eski event'in kaldırılma tarihi consumer migration durumu ve retention içindeki geçmiş mesajlar dikkate alınarak belirlenmelidir.

Schema Evolution

İlk tercih uyumlu schema evolution olmalıdır. Optional field eklemek yeni event type oluşturmaktan daha sade olabilir. Consumer'lar bağımsız migrate olabilir. Registry compatibility kontrolü güvenlik sağlar. Gereksiz version patlaması önlenir.

Event Type Version

Event type adına version eklemek breaking contract'ı ayırabilir. OrderCreated.v2 gibi yapı kullanılabilir. Consumer hangi version'ı desteklediğini açıkça seçer. Producer geçiş döneminde iki event yayınlayabilir. Dual publication süresi sınırlı tutulmalıdır.

Topic Version

Breaking change için yeni topic oluşturmak güçlü izolasyon sağlar. V1 ve V2 ayrı retention ve consumer group'lara sahip olur. Operasyon maliyeti artar. Topic sayısı büyüyebilir. Migration tamamlandıktan sonra eski topic deprecation sürecine alınmalıdır.

V1 ve V2 Event'leri Birlikte Desteklemek

Transition döneminde iki version birlikte çalışabilir. Producer dual publish yapabilir. Alternatif olarak adapter V1'i V2'ye çevirebilir. Consumer migration durumu catalog üzerinden izlenmelidir. Sonsuz süre iki version desteklemek bakım yükü oluşturur.

Eski Event'i Ne Zaman Kaldırmalı?

Tüm aktif consumer'lar yeni version'a geçtiğinde deprecation düşünülebilir. Retention içindeki eski event'lerin replay ihtiyacı kontrol edilmelidir. Audit ve disaster recovery planı etkilenebilir. Owner onayı alınmalıdır. Kaldırma tarihi önceden duyurulmalıdır.

Event Metadata Standardı

Event metadata standardı farklı servislerin aynı tracing ve governance dilini kullanmasını sağlar. Event ID benzersizliği, timestamp zamanı ve event type semantiği temel alanlardır. Correlation ID business flow'u, causation ID olay zincirini takip etmeyi kolaylaştırır. Trace Context distributed tracing ile event akışını bağlar. Kurum genelinde standart envelope kullanmak observability ve event tooling kalitesini belirgin biçimde artırır.

Event ID

Event ID her event instance için benzersiz kimliktir. Duplicate detection için kullanılabilir. Replay sırasında aynı event aynı ID'yi korumalıdır. Log ve trace aramalarında temel anahtardır. Format standardı belirlenmelidir.

Event Type

Event Type event'in business anlamını belirtir. OrderCreated gibi isimler tercih edilebilir. Teknik class adı olmamalıdır. Version ihtiyacı varsa convention tanımlanmalıdır. Consumer routing bu alanı kullanabilir.

Source

Source event'i üreten sistem veya domain'i belirtir. CloudEvents benzeri standarda uyabilir. Fiziksel host adından daha kararlı bir kimlik tercih edilmelidir. Ownership bulmayı kolaylaştırır. Event catalog ile eşleştirilebilir.

Timestamp

Timestamp event'in gerçekleşme zamanını belirtir. UTC formatı tercih edilebilir. Processing time ile karıştırılmamalıdır. Clock skew dikkate alınmalıdır. Event ordering için tek başına garanti değildir.

Schema Version

Schema Version payload contract sürümünü gösterir. Consumer parsing davranışını belirleyebilir. Registry ID ile birlikte kullanılabilir. Version semantiği dokümante edilmelidir. Gereksiz manual increment süreci önlenmelidir.

Correlation ID

Correlation ID aynı business flow içindeki mesajları bağlar. HTTP request'ten event zincirine taşınabilir. Log aramasını kolaylaştırır. Saga takibinde değerlidir. Her consumer yeni correlation ID üretmemelidir.

Causation ID

Causation ID mevcut event'i tetikleyen önceki message ID'sini gösterir. Event zinciri yönünü anlamayı kolaylaştırır. Root cause analizinde değerlidir. Saga adımlarında kullanılabilir. Correlation ID ile aynı amaçta değildir.

Trace Context

Trace Context distributed tracing bilgisini taşır. W3C traceparent standardı kullanılabilir. Producer span ile consumer span arasında bağ kurulur. OpenTelemetry bu veriyi propagate edebilir. Sampling politikası tüm servislerde uyumlu olmalıdır.

CloudEvents Nedir?

CloudEvents event metadata için standart bir envelope tanımlar. id, source, type ve time gibi alanlar farklı sistemlerin ortak event biçimi kullanmasına yardımcı olur. datacontenttype payload formatını, subject ise event'in ilgili olduğu kaynağı belirtebilir. Standardizasyon farklı broker ve platformlar arasında taşınabilirliği artırır. CloudEvents kullanmak business schema governance ihtiyacını ortadan kaldırmaz, yalnızca envelope seviyesinde ortak dil sağlar.

Standard Event Envelope

Standard Event Envelope temel metadata alanlarını aynı yapı altında toplar. Producer'lar ortak contract kullanır. Tooling bu alanlara güvenebilir. Broker bağımlılığı azaltılabilir. Business data ayrı payload içinde tutulur.

id

id event instance kimliğidir. Benzersiz olması beklenir. Deduplication için kullanılabilir. Replay sırasında korunmalıdır. Log aramasında temel anahtardır.

source

source event'in üretildiği bağlamı tanımlar. URI benzeri değer kullanılabilir. Service owner'ı bulmaya yardımcı olur. Fiziksel deployment detayından bağımsız tutulması faydalıdır. Naming standardı belirlenmelidir.

type

type event türünü belirtir. Domain anlamını yansıtmalıdır. Consumer filter bu alanı kullanabilir. Version semantiği convention ile belirlenebilir. Gereksiz teknik detay taşımamalıdır.

time

time event'in oluşum zamanını taşır. Standart timestamp formatı kullanılır. Processing time farklı olabilir. Event latency hesaplamasında kullanılabilir. Clock skew dikkate alınmalıdır.

datacontenttype

datacontenttype data alanının serialization formatını açıklar. application/json buna örnektir. Consumer parsing davranışını kolaylaştırır. Binary formatlarda uygun media type kullanılabilir. Contract yine schema üzerinden yönetilmelidir.

subject

subject event'in ilişkili olduğu kaynağı belirtir. Order ID gibi değerler kullanılabilir. Filtering ve observability için faydalıdır. Hassas identifier taşıma riski değerlendirilmelidir. Partition key ile aynı olmak zorunda değildir.

Farklı Broker'lar Arasında Standardizasyon

CloudEvents farklı messaging platformlarında ortak metadata modeli sunabilir. Kafka, HTTP veya cloud event bus arasında envelope korunabilir. Tooling daha tekrar kullanılabilir hâle gelir. Migration maliyeti azalabilir. Transport özellikleri yine broker'a özgü kalır.

Correlation ID ve Causation ID

Correlation ID bir business flow içindeki tüm işlemleri aynı bağlam altında toplar. Causation ID ise hangi mesajın yeni mesajı tetiklediğini gösterir. İkisi birlikte kullanıldığında event zincirini hem yatay hem de nedensel olarak izlemek kolaylaşır. Distributed debugging ve Saga takibinde ciddi fayda sağlar. Bu metadata event üretim helper'ları tarafından otomatik taşınırsa ekiplerin manuel hata yapma ihtimali azalır.

Correlation ID

Correlation ID aynı business operation boyunca korunur. HTTP request'te üretilebilir. Sonraki event'lere aktarılır. Farklı servis logları bu değerle aranabilir. Yeni bağımsız işlem başladığında yeni correlation oluşturulabilir.

Aynı Business Flow

Aynı sipariş oluşturma akışı birçok servisten geçebilir. Correlation ID tüm adımlarda aynı kalır. Ödeme ve bildirim event'leri aynı flow altında görülür. Incident analizi hızlanır. Business journey ölçümü de kolaylaşır.

Causation ID

Causation ID mevcut event'i doğrudan tetikleyen message ID'sidir. Parent-child ilişkisi kurar. Event chain graph oluşturulabilir. Loop tespiti kolaylaşabilir. Saga adımları daha anlaşılır olur.

Hangi Event Hangisini Tetikledi?

Bir event başka bir command veya event üretebilir. Causation ID önceki message ID'yi taşır. Böylece zincirin yönü görülür. Root event'e kadar geri takip yapılabilir. Karmaşık akışlarda debugging süresi azalır.

Distributed Debugging

Dağıtık sistemlerde tek request birçok servise yayılabilir. Correlation ve causation ID ortak iz sağlar. Log query sonuçları daha anlamlı olur. Trace sampling yoksa bile temel bağlantı korunabilir. Event ID ile birlikte kullanılması önerilir.

Saga Takibi

Saga birden fazla local transaction içerir. Correlation ID tüm Saga instance'ını bağlar. Causation ID adımların tetik ilişkisini gösterir. Orchestrator state ile karşılaştırma yapılabilir. Compensation nedeninin bulunması kolaylaşır.

Saga Pattern Nedir?

Saga Pattern birden fazla servis arasında çalışan business transaction'ı küçük local transaction adımlarına böler. Her servis kendi database transaction'ını yönetir. Adımların biri başarısız olduğunda önceki işlemlerin etkisi compensating transaction ile dengelenebilir. Bu yaklaşım distributed transaction yerine eventual consistency modelini kabul eder. Karmaşık business flow'larda Saga state, idempotency ve observability birlikte tasarlanmalıdır.

Distributed Transaction Problemi

Birden fazla servis tek ACID transaction paylaşamaz. İki phase commit her altyapıda uygun değildir. Availability ve operasyon maliyeti artabilir. Saga local transaction'ları koordine eder. Failure compensation ile yönetilir.

Local Transaction

Her Saga step kendi servis database'inde local transaction çalıştırır. Commit bağımsızdır. Sonraki step event veya command ile tetiklenebilir. Failure durumunda önceki commit geri alınamaz. Compensation yeni transaction olarak uygulanır.

Saga Steps

Saga Steps business workflow'un sıralı veya koşullu adımlarıdır. ReserveInventory, CapturePayment gibi işler olabilir. Her step açık state taşır. Timeout ve retry politikası belirlenir. Idempotency her adım için gerekir.

Compensating Transaction

Compensating Transaction önceki business effect'i tersine çevirmeye çalışır. Gerçek database rollback değildir. RefundPayment veya ReleaseInventory buna örnektir. Compensation da başarısız olabilir. Bu nedenle retry ve manual intervention planı gerekir.

Eventual Consistency

Saga tamamlanana kadar servis state'leri geçici olarak farklı olabilir. Bu eventual consistency davranışıdır. Kullanıcı arayüzü pending state gösterebilir. Reconciliation işleri eksik flow'ları tespit edebilir. Business ekipleri bu modeli anlamalıdır.

Saga Choreography

Saga Choreography modelinde merkezi bir orchestrator bulunmaz. Her servis aldığı event'e tepki verir ve gerekirse yeni event yayınlar. Loose coupling ve bağımsızlık açısından çekici bir modeldir. Fakat servis sayısı ve adım sayısı arttıkça workflow'u zihinde takip etmek zorlaşabilir. Correlation ID, event catalog ve distributed tracing olmadan büyük choreography akışları operasyon açısından zorlayıcı olabilir.

Merkezi Orchestrator Yoktur

Choreography akışında tek koordinatör servis bulunmaz. Her participant kendi event handler'ına sahiptir. Akış event zinciriyle ilerler. Merkezi failure point azalabilir. Business flow görünürlüğü ayrıca sağlanmalıdır.

Her Service Event'e Tepki Verir

Servis ilgili event'i subscribe eder. Local transaction çalıştırır. Başarılıysa yeni event yayınlayabilir. Failure için compensation event üretilebilir. Loop ve duplicate davranışı kontrol edilmelidir.

Loose Coupling

Servisler birbirini doğrudan çağırmaz. Event contract üzerinden bağlantı kurulur. Yeni consumer eklemek kolaydır. Ancak semantik coupling devam eder. Schema governance yine gereklidir.

Karmaşık Akışların İzlenebilirliği

Adım sayısı arttıkça choreography takibi zorlaşır. Tek workflow state merkezi yerde görünmeyebilir. Distributed trace kritik hâle gelir. Event catalog hangi servisin ne tükettiğini göstermelidir. Operasyon dashboard business flow seviyesinde tasarlanmalıdır.

Saga Orchestration

Saga Orchestration modelinde merkezi bir orchestrator workflow adımlarını yönetir. Orchestrator hangi command'in hangi sırayla gönderileceğini bilir. State machine üzerinden Saga'nın mevcut durumunu takip eder. Bu yapı karmaşık workflow görünürlüğünü artırır. Buna karşılık orchestrator'ın business akışına fazla bağlanması ve merkezi koordinasyon noktası hâline gelmesi dikkatle yönetilmelidir.

Merkezi Saga Orchestrator

Orchestrator workflow koordinasyonunu üstlenir. Participant servislerin iç business logic'ini yönetmemelidir. Hangi adımın sırada olduğunu bilir. Timeout ve compensation kararlarını takip eder. State persistence güvenilir olmalıdır.

Command Gönderimi

Orchestrator participant servislere command gönderebilir. ReserveInventory buna örnektir. Servis sonucu event olarak bildirebilir. Correlation ID Saga instance'ını bağlar. Command idempotency önemlidir.

State Machine

State Machine Saga'nın current step bilgisini tutar. PendingPayment veya Compensating gibi durumlar olabilir. Transition kuralları açıkça tanımlanır. Unexpected event davranışı belirlenir. Recovery state üzerinden yapılabilir.

Daha Kolay Workflow Görünürlüğü

Orchestrator Saga state'ini merkezi olarak gösterir. Hangi adımda takıldığı kolay anlaşılır. Operasyon ekranı oluşturmak daha basittir. Business kullanıcıları pending işlemleri görebilir. Bu görünürlük uzun flow'larda değerlidir.

Orchestrator Coupling Riski

Orchestrator çok fazla domain detayı öğrenirse merkezi monolith davranışı oluşabilir. Participant service autonomy azalır. Her değişiklik orchestrator deployment gerektirebilir. Sadece workflow coordination burada tutulmalıdır. Domain kararları ilgili servislerde kalmalıdır.

Choreography vs Orchestration

Choreography küçük ve doğal event akışlarında sade bir çözüm sunabilir. Orchestration adım sayısı ve business branching arttığında workflow görünürlüğünü güçlendirir. Choreography servis bağımsızlığını artırırken debugging maliyetini yükseltebilir. Orchestration merkezi state sunar fakat coordinator coupling riski taşır. Seçim servis sayısı, workflow uzunluğu, compensation gereksinimi ve operasyon ekibinin görünürlük ihtiyacına göre yapılmalıdır.

Servis Sayısı

Az sayıda servis choreography ile rahat yönetilebilir. Servis sayısı büyüdükçe event zinciri uzar. Orchestrator workflow'u daha görünür kılabilir. Tek metrik karar değildir. Domain ownership yapısı da önemlidir.

Workflow Karmaşıklığı

Basit doğrusal akış choreography için uygundur. Çok sayıda branch ve timeout orchestration lehine olabilir. Compensation ağacı büyüdükçe state machine fayda sağlar. Business rule sıklığı değerlendirilmelidir. Gereksiz orchestrator eklemek de maliyet yaratır.

Debugging

Choreography debugging için güçlü tracing gerektirir. Orchestration merkezi state sayesinde bazı sorunları kolaylaştırır. Her iki modelde event ID ve correlation ID kullanılmalıdır. DLQ ve retry görünürlüğü gerekir. Incident tooling mimariyle birlikte tasarlanmalıdır.

Coupling

Choreography direct service coupling'i azaltır. Event contract coupling'i devam eder. Orchestration coordinator'ı workflow'a bağlar. Participant servisler yine bağımsız domain logic taşır. Coupling türünü doğru değerlendirmek gerekir.

Business Visibility

Orchestration business flow durumunu merkezi gösterir. Choreography'de görünürlük event stream üzerinden türetilebilir. Operasyon ekipleri pending Saga listesini görmek isteyebilir. Regulated süreçlerde audit gereksinimi etkili olabilir. Visibility ihtiyacı seçimde önemlidir.

Hangi Senaryoda Hangisi?

Üç dört basit event tepkisi için choreography yeterli olabilir. Uzun ve compensation yoğun workflow'larda orchestration daha yönetilebilir olabilir. Ekip deneyimi kararı etkiler. Her flow için tek model kullanmak zorunlu değildir. Aynı sistem farklı Saga desenlerini birlikte kullanabilir.

Compensation Başarısız Olursa Ne Olur?

Compensation da normal business operation gibi başarısız olabilir. Refund endpoint'i unavailable olabilir veya inventory release geçici hata verebilir. Bu durumda compensation retry uygulanmalıdır. Belirli sınırdan sonra manual intervention ve incident alert devreye girebilir. Saga state başarısız compensation durumunu açıkça göstermeli ve reconciliation süreci eksik işlemleri düzenli olarak kontrol etmelidir.

Compensation Retry

Compensation geçici hata aldığında tekrar denenebilir. Exponential backoff kullanılabilir. Operation idempotent olmalıdır. Aynı refund iki kez yapılmamalıdır. Maximum attempts sonrası escalation gerekir.

Manual Intervention

Otomatik recovery mümkün değilse insan müdahalesi gerekir. Operasyon ekranı Saga state'i göstermelidir. Güvenli action butonları sunulabilir. Yapılan değişiklik audit altında tutulmalıdır. Critical transaction'larda çift onay gerekebilir.

Saga State

Saga State mevcut workflow durumunu kaydeder. CompensationFailed gibi açık state olabilir. Retry count tutulabilir. Son error details saklanabilir. Recovery worker bu state üzerinden devam edebilir.

Incident Alert

Compensation failure business riski taşıyabilir. Alert severity event type'a göre belirlenmelidir. Ödeme iadesi hatası yüksek öncelikli olabilir. Alert correlation ID içermelidir. Owner doğrudan bulunabilmelidir.

Reconciliation

Reconciliation sistem state'leri arasındaki uyumsuzlukları düzenli kontrol eder. Eksik compensation tespit edilebilir. External provider state ile local state karşılaştırılabilir. Otomatik düzeltme veya manual case açılabilir. Dağıtık sistem güvenilirliğinin önemli güvenlik ağıdır.

CQRS ve Event-Driven Architecture

CQRS command ve query modellerini birbirinden ayıran bir tasarım yaklaşımıdır. Event-driven architecture ile birlikte kullanıldığında write model değişiklikleri event olarak read model'e aktarılabilir. Projection consumer'ları sorgu için optimize edilmiş tablo veya index'leri günceller. Bu yapı read performansını ve model bağımsızlığını artırabilir. Buna karşılık read model ile command model arasında eventual consistency oluşur ve kullanıcı deneyimi buna göre tasarlanmalıdır.

Command Model

Command Model write işlemleri ve business kurallarını yönetir. Aggregate validation burada yapılabilir. Transaction ana state'i günceller. Event üretilebilir. Model query performansı için optimize edilmek zorunda değildir.

Query Model

Query Model okuma ihtiyaçları için optimize edilir. Denormalized tablo kullanılabilir. Search index buna örnek olabilir. Write model'den ayrı storage kullanabilir. Event'ler üzerinden güncellenebilir.

Projection

Projection event'lerden query state üreten consumer'dır. OrderCreated event'i read table'a kayıt ekleyebilir. Update event'leri projection'ı değiştirir. Replay ile yeniden inşa edilebilir. Idempotent ve ordering-aware olmalıdır.

Event ile Read Model Güncelleme

Write commit sonrası integration event yayınlanır. Projection consumer event'i alır. Read model'i günceller. Kullanıcı kısa süre eski veri görebilir. Lag SLO ile sınırlandırılmalıdır.

Eventual Consistency

Command sonucu ile read model aynı anda güncel olmayabilir. Bu CQRS event akışının doğal sonucudur. UI pending state gösterebilir. Kritik ekranda write model sonucu geçici olarak gösterilebilir. Business kullanıcıları bu gecikmenin sınırını bilmelidir.

Event Sourcing Nedir?

Event Sourcing uygulama state'ini yalnızca son değer olarak saklamak yerine state değişikliklerini event dizisi biçiminde kalıcı hâle getiren persistence modelidir. Aggregate mevcut durumu geçmiş event'lerin replay edilmesiyle yeniden oluşturulabilir. Event Store append-only geçmiş sağlar. Çok uzun stream'lerde snapshot performansı iyileştirebilir. Event Sourcing güçlü audit ve temporal imkanlar sunar, ancak domain ve operasyon tarafında ek sorumluluk getirir.

State Yerine Event'leri Kalıcı Hale Getirmek

Klasik model current row'u saklar. Event Sourcing değişiklik geçmişini event olarak tutar. Current state event'lerden hesaplanır. Her event immutable kabul edilir. Hatalı geçmişi düzeltmek yeni event gerektirir.

Event Store

Event Store aggregate event stream'lerini saklar. Append işlemi ana davranıştır. Expected version optimistic concurrency sağlayabilir. Stream per aggregate modeli kullanılabilir. Backup ve retention kritik önemdedir.

Aggregate Rehydration

Aggregate Rehydration geçmiş event'lerin sırayla uygulanmasıdır. İlk event'ten başlanabilir. Her event state transition yapar. Çok uzun history latency oluşturabilir. Snapshot bu maliyeti azaltır.

Snapshot

Snapshot belirli version'daki aggregate state kopyasıdır. Rehydration snapshot'tan başlayabilir. Sonraki event'ler uygulanır. Snapshot authoritative history değildir. Bozulduğunda event stream'den yeniden üretilebilir.

Replay

Replay event history'nin yeniden işlenmesidir. Projection rebuild yapılabilir. Yeni business rule migration için kullanılabilir. Side effect olmadan çalışmalıdır. Versioned event handler stratejisi gerekebilir.

Event Sourcing ile Event-Driven Architecture Aynı Şey mi?

Event Sourcing ile Event-Driven Architecture aynı kavram değildir. EDA servisler ve bileşenler arasındaki iletişim modelidir. Event Sourcing ise state'in nasıl kalıcı tutulduğunu tanımlayan persistence yaklaşımıdır. Bir sistem event-driven olup klasik relational database state saklayabilir. Benzer şekilde event-sourced aggregate internal kullanılıp dış entegrasyonların tamamı senkron tasarlanabilir.

EDA Bir İletişim Modelidir

EDA event'lerin producer'dan consumer'a aktarılmasını ele alır. Broker veya event bus kullanılabilir. Asenkron messaging yaygındır. Domain state nasıl tutuluyor sorusuna cevap vermez. Bu nedenle persistence modelinden ayrıdır.

Event Sourcing Bir Persistence Modelidir

Event Sourcing state geçmişini event olarak saklar. Aggregate state replay ile üretilir. Event Store ana veri kaynağıdır. Messaging broker zorunlu değildir. Integration event ayrıca üretilebilir.

Birlikte Kullanılabilirler

Event-sourced aggregate yeni domain event üretebilir. Bu event integration event olarak broker'a yayınlanabilir. Projection'lar event-driven çalışabilir. Birlikte güçlü model oluştururlar. Buna rağmen operasyon yükü arttığı için gerçek ihtiyaç olmalıdır.

Her EDA Sistemi Event-Sourced Değildir

Çoğu event-driven backend klasik database kullanır. Business state normal table'da tutulabilir. Outbox ile event yayınlanabilir. Event Sourcing zorunlu değildir. Gereksiz kullanım domain development maliyetini artırabilir.

Event Replay Nedir?

Event Replay geçmişte broker veya event store üzerinde tutulan event'lerin yeniden tüketilmesidir. Yeni consumer geçmiş veriden kendi local state'ini oluşturabilir. Projection bozulduğunda sıfırdan yeniden inşa edilebilir. Incident recovery ve backfill süreçlerinde de replay güçlü bir araçtır. Ancak side effect üreten consumer'larda replay güvenliği özel olarak tasarlanmalıdır.

Geçmiş Event'leri Yeniden Okumak

Kafka retention içindeki event'ler offset geriye alınarak okunabilir. Event Store stream'i baştan replay edilebilir. Consumer aynı contract version'larını anlayabilmelidir. Processing kapasitesi planlanmalıdır. Replay production traffic'i etkilememelidir.

Yeni Consumer Oluşturmak

Yeni consumer geçmiş event'leri kullanarak kendi state'ini oluşturabilir. Producer'dan yeni API istemek gerekmeyebilir. Bu event-driven platformun güçlü avantajıdır. Retention yeterli olmalıdır. Eski schema version'ları desteklenmelidir.

Projection Yeniden İnşa Etmek

Projection hatalıysa mevcut read model silinip replay yapılabilir. Event history kaynak olarak kullanılır. Side effect yalnızca projection update olmalıdır. Yeni projection version paralel oluşturulabilir. Cutover sonrası eski model kaldırılabilir.

Incident Recovery

Consumer bug nedeniyle event'leri yanlış işlemiş olabilir. Bug düzeltildikten sonra ilgili offset aralığı replay edilebilir. Idempotency kontrolü gerekir. Daha önce oluşmuş external side effect ayrılmalıdır. Recovery planı incident öncesinde test edilmelidir.

Backfill

Backfill geçmiş veriyi yeni feature için işlemektir. Yeni field veya analytics model geçmiş event'lerden üretilebilir. Replay cluster yükü oluşturabilir. Rate limiting uygulanmalıdır. Business timestamp korunmalıdır.

Replay Neden Tehlikeli Olabilir?

Replay consumer'ın daha önce yaptığı side effect'leri tekrar üretme riski taşır. E-posta yeniden gönderilebilir veya aynı ödeme talebi ikinci kez çağrılabilir. External API'ler idempotency garantisi sunmuyorsa risk daha büyüktür. Replay-safe consumer replay modunu tanıyabilir veya side effect suppression uygulayabilir. Production öncesinde replay testi yapmak event-driven recovery planının önemli parçasıdır.

Tekrar E-posta Gönderme

Notification consumer replay sırasında geçmiş e-postaları tekrar gönderebilir. Kullanıcı deneyimi bozulur. Replay mode notification'ı suppress edebilir. Sent notification table kontrol edilebilir. Business requirement açık olmalıdır.

Tekrar Ödeme Alma

Payment side effect replay için en riskli örneklerden biridir. Aynı charge iki kez uygulanmamalıdır. External provider idempotency key kullanılmalıdır. Payment record unique business key taşımalıdır. Replay dry-run ile doğrulanmalıdır.

External API Side Effect

External API local transaction kontrolü dışında çalışır. Response timeout olsa bile operation tamamlanmış olabilir. Replay aynı çağrıyı tekrar yapabilir. Idempotency contract varsa kullanılmalıdır. Yoksa reconciliation şarttır.

Replay-Safe Consumer

Replay-Safe Consumer aynı event'i yeniden işlediğinde kontrollü davranır. Idempotency temel gereksinimdir. External side effect'leri ayırabilir. Replay context metadata kullanılabilir. Test suite gerçek replay senaryosu içermelidir.

Side Effect Suppression

Side Effect Suppression replay sırasında belirli dış etkileri devre dışı bırakır. Projection update devam edebilir. E-posta veya webhook gönderimi atlanabilir. Bu davranış gizli flag yerine açık processing mode ile yönetilmelidir. Audit log hangi etkilerin suppress edildiğini göstermelidir.

Kafka Retention ve Log Compaction

Kafka retention event'lerin broker üzerinde ne kadar süre tutulacağını belirler. Time-based retention belirli yaştan eski segmentleri silebilir. Size-based retention storage miktarını sınırlar. Log compaction ise aynı key için en güncel kaydı korumaya odaklanır. Tombstone event belirli key'in silindiğini compaction sürecine bildirmek için kullanılabilir.

Time-Based Retention

Time-Based Retention mesaj yaşına göre silme yapar. Yedi gün veya otuz gün gibi süre belirlenebilir. Replay penceresini doğrudan etkiler. Storage kapasitesiyle dengelenmelidir. Compliance retention gereksinimleri ayrıca değerlendirilmelidir.

Size-Based Retention

Size-Based Retention topic veya partition storage limitine göre çalışır. Disk kullanımını sınırlar. Yüksek trafik durumunda retention süresi beklenenden kısa olabilir. Replay planı etkilenir. Capacity planning mesaj hacmini dikkate almalıdır.

Log Compaction

Log Compaction aynı key için en son değeri korumayı hedefler. Tam event history garantisi değildir. State snapshot benzeri stream'lerde faydalıdır. Aynı key'in eski kayıtları zamanla temizlenir. Consumer davranışı buna göre tasarlanmalıdır.

Message Key

Compaction message key üzerinden çalışır. Key entity identity olabilir. Null key farklı davranabilir. Key değişikliği state history'yi bölebilir. Naming ve serialization kararlı olmalıdır.

Tombstone

Tombstone key içeren ve value kısmı null olan kayıt olabilir. Compaction ilgili key'in silinmesini sağlar. Consumer delete state olarak yorumlayabilir. Retention süreci anlık silme sağlamayabilir. Privacy gereksinimleri ayrıca değerlendirilmelidir.

Topic Tasarımı Nasıl Yapılmalı?

Topic tasarımı event platformunun uzun vadeli operasyon maliyetini belirler. Event type başına topic sade isolation sağlar ancak topic sayısını hızla artırabilir. Domain başına topic operasyonu azaltırken çok sayıda event type aynı yerde toplanabilir. Aggregate veya bounded context yaklaşımı orta yol sunabilir. En iyi model event ownership, retention, scaling, ACL ve schema lifecycle gereksinimlerine göre seçilmelidir.

Event Type Başına Topic

Her event type ayrı topic kullanabilir. Retention ve ACL bağımsız yönetilir. Consumer discovery kolaylaşır. Topic sayısı hızla artabilir. Platform otomasyonu güçlü olmalıdır.

Aggregate Başına Topic

Aynı aggregate event'leri tek topic'te tutulabilir. Ordering key doğal olur. Consumer birden fazla event type okuyabilir. Schema dispatch gerekir. Domain sınırı anlaşılır kalmalıdır.

Domain Başına Topic

Bir domain'in birçok event'i aynı topic'te olabilir. Topic sayısı azalır. Consumer filtreleme yapmak zorunda kalabilir. Retention tüm event'ler için ortak olur. Çok farklı trafik profilleri sorun yaratabilir.

Çok Fazla Topic'in Operasyon Maliyeti

Her topic metadata ve configuration yükü getirir. Partition sayısı cluster kaynaklarını etkiler. Monitoring dashboard büyür. ACL yönetimi zorlaşır. Otomasyon olmadan binlerce topic operasyon yükü oluşturabilir.

Bir Topic'te Çok Event Type Riski

Tek topic çok farklı event contract taşıyabilir. Consumer gereksiz mesaj okuyabilir. Retention ihtiyacı çatışabilir. Schema yönetimi zorlaşabilir. Domain sınırı yerine teknik kolaylıkla birleşim yapılmamalıdır.

Topic Naming Convention

Topic isimleri event platformunda discoverability ve governance açısından önemlidir. Domain, entity, event ve version gibi bileşenler kullanılabilir. Environment bilgisinin topic adına eklenmesi bazı deployment modellerinde faydalı olabilir. İsimlerde implementation teknolojisine gereksiz yer vermemek uzun vadeli taşıma kolaylığı sağlar. Naming convention otomatik validation ile platform seviyesinde uygulanabilir.

Domain

Domain adı ownership bağlamını gösterir. orders veya payments buna örnektir. Consumer ilgili alanı kolay bulur. Organizasyon yapısı yerine business domain tercih edilebilir. Domain değişikliği nadir olmalıdır.

Entity

Entity topic'in hangi business nesnesiyle ilgili olduğunu gösterebilir. order veya invoice gibi isimler kullanılabilir. Her sistemde gerekli değildir. Çok uzun isimlerden kaçınılmalıdır. Naming standardı ekipler arasında tutarlı olmalıdır.

Event

Event adı gerçekleşmiş business fact'i belirtir. created veya completed gibi geçmiş zaman semantiği kullanılabilir. Command isimleri aynı convention'a karışmamalıdır. Event type metadata ayrıca taşınabilir. Topic adı contract'ı tamamen temsil etmek zorunda değildir.

Version

Version breaking migration durumunda topic adına eklenebilir. v1 ve v2 geçici olarak birlikte çalışabilir. Her küçük schema değişikliğinde version değiştirmek gerekmez. Compatibility evolution tercih edilmelidir. Eski version deprecation planına bağlanmalıdır.

Environment

Environment dev, test veya prod ayrımı için kullanılabilir. Bazı platformlar cluster seviyesinde zaten ayırır. Aynı cluster kullanılıyorsa topic prefix faydalı olabilir. Yanlış environment publish riskini azaltır. IAM politikası ayrıca korunmalıdır.

İsimlerde Teknik Uygulama Detaylarından Kaçınmak

Topic adı service implementation veya framework adına bağlanmamalıdır. orders-service-v3-node gibi isimler zamanla anlamsızlaşabilir. Business domain daha kararlı bir referanstır. Service yeniden yazılsa bile event contract aynı kalabilir. Böylece infrastructure migration daha kolay olur.

Event Governance Nedir?

Event Governance kurum içindeki event'lerin sahipliğini, contract yaşam döngüsünü ve kullanım kurallarını yönetir. Event owner ve schema owner sorumlulukları açık olmalıdır. Producer ve consumer catalog hangi sistemlerin birbirine bağlı olduğunu görünür kılar. Deprecation policy eski event'lerin kontrollü kaldırılmasını sağlar. Kurumsal event-driven backend ve mikroservis mimarisi geliştirme hizmeti sunulurken teknoloji kurulumundan önce bu yönetişim yapısının tasarlanması uzun vadede büyük fark yaratır.

Event Owner

Event Owner business semantiğinden sorumludur. Contract değişikliklerini değerlendirir. Consumer etkisini takip eder. Incident sırasında doğru ekip bulunur. Ownership catalog içinde görünür olmalıdır.

Schema Owner

Schema Owner teknik contract lifecycle'ını yönetebilir. Compatibility policy uygular. Version değişikliklerini review eder. Event Owner ile birlikte çalışır. Organizasyona göre iki rol aynı ekipte olabilir.

Producer Owner

Producer Owner event'i yayınlayan servisten sorumludur. Publish SLO ve error rate takip eder. Outbox veya retry davranışını işletir. Contract ihlallerini düzeltir. Deployment değişikliklerini consumer etkisiyle değerlendirmelidir.

Consumer Catalog

Consumer Catalog hangi servisin hangi event'i tükettiğini gösterir. Breaking change impact analysis için değerlidir. Owner bilgisi tutulabilir. Son aktif kullanım zamanı kaydedilebilir. Otomatik runtime discovery ile güncel tutulabilir.

Event Documentation

Event Documentation yalnızca field listesinden ibaret değildir. Event ne zaman üretilir açıklanmalıdır. Business semantiği yazılmalıdır. Delivery ve ordering beklentisi belirtilmelidir. Örnek payload geliştiricilere yardımcı olur.

Deprecation Policy

Deprecation Policy eski event version'ların nasıl kaldırılacağını tanımlar. Önceden duyuru süresi belirlenebilir. Consumer migration deadline verilir. Usage metriği kaldırma kararını destekler. Ani delete production incident riskini artırır.

Event Catalog Neden Gereklidir?

Event Catalog kurumda hangi event'lerin bulunduğunu keşfetmeyi kolaylaştırır. Kim üretiyor, kim tüketiyor ve schema nedir sorularına merkezi cevap verir. SLA ve SLO bilgileri entegrasyon beklentisini netleştirir. Owner alanı incident sırasında doğru ekibe ulaşmayı sağlar. Event sayısı arttıkça catalog geliştirici deneyimi ve governance için temel platform bileşenlerinden birine dönüşür.

Hangi Event'ler Var?

Catalog mevcut event type'ları listeler. Yeni ekip duplicate event üretmeden önce arama yapabilir. Domain filtreleri kullanılabilir. Deprecated event'ler işaretlenebilir. Discoverability artar.

Kim Üretiyor?

Her event için producer service bilgisi tutulur. Owner ekibi gösterilebilir. Publish endpoint veya topic kaydedilebilir. Incident sırasında source hızla bulunur. Producer version bilgisi gerekirse eklenebilir.

Kim Tüketiyor?

Consumer listesi dependency map oluşturur. Breaking change etkisi görülebilir. Aktif ve pasif consumer ayrılabilir. Runtime telemetry ile otomatik güncelleme yapılabilir. Shadow consumer'lar fark edilebilir.

Schema Nedir?

Catalog Schema Registry kaydına link verebilir. Field açıklamaları gösterilebilir. Example payload bulunabilir. Version history izlenebilir. Consumer geliştiricisi hızlı başlangıç yapar.

SLA/SLO Nedir?

Event processing beklentisi catalog içinde belirtilebilir. p95 latency hedefi yazılabilir. Retention ve availability değeri gösterilebilir. Consumer kritikliği anlaşılır. Incident priority buna göre ayarlanabilir.

Owner Kim?

Owner teknik veya business sorumluyu gösterir. İletişim kanalı eklenebilir. Schema change review için kullanılır. DLQ incident'leri doğru ekibe gider. Sahipsiz event kabul edilmemelidir.

Event-Driven Sistemlerde Observability

Event-driven sistemlerde observability metrics, logs ve traces birlikte kullanıldığında anlamlıdır. Broker metrics altyapı sağlığını gösterirken producer ve consumer metrics uygulama davranışını açıklar. Event ID, correlation ID ve trace context uçtan uca akışı birleştirir. Queue depth, consumer lag ve DLQ rate yalnızca teknik metrik değil, business gecikmesinin de göstergesi olabilir. Production sisteminde gözlemlenmeyen asenkron akış, hata anında ekip için görünmez bir kara kutuya dönüşür.

Metrics

Metrics sistem davranışını sayısal olarak gösterir. Publish rate ve processing rate temel örneklerdir. Error ve retry oranları takip edilmelidir. Histogram latency dağılımını gösterir. SLO alarmı metrics üzerinden kurulabilir.

Logs

Logs tekil event processing ayrıntısını verir. Event ID ile aranabilir. Payload tam olarak loglanmamalıdır. Error code ve result tutulabilir. Structured logging tercih edilmelidir.

Traces

Traces event akışını servisler arasında takip eder. Producer span publish işlemini gösterir. Consumer span processing süresini ölçer. W3C trace context taşınabilir. Sampling kritik flow'larda uygun seçilmelidir.

Broker Metrics

Broker Metrics disk, throughput ve replication durumunu gösterir. Kafka partition health izlenebilir. RabbitMQ queue depth takip edilir. Connection sayısı önemlidir. Kapasite alarmı bu metriklere dayanır.

Producer Metrics

Producer Metrics publish rate ve error rate içerir. Publish latency network sorunlarını gösterebilir. Retry rate broker veya network problemi sinyali olabilir. Batch size throughput tuning için kullanılır. Message size trendi capacity planning'e yardım eder.

Consumer Metrics

Consumer Metrics processing rate ve latency gösterir. Error rate kod problemi işareti olabilir. Consumer lag backlog seviyesini belirtir. Retry ve DLQ rate resiliency davranışını gösterir. Instance bazlı dağılım hot consumer sorunlarını açığa çıkarır.

İzlenmesi Gereken Producer Metrikleri

Producer tarafında yalnızca kaç mesaj yayınlandığını izlemek yeterli değildir. Publish error rate ve publish latency broker bağlantı problemlerini erken gösterebilir. Retry rate yükselmesi geçici veya sürekli altyapı sorununa işaret edebilir. Batch size ile message size throughput ve network kullanımını doğrudan etkiler. Producer dashboard deployment sonrası davranış değişikliklerini hızlı fark edecek şekilde tasarlanmalıdır.

Publish Rate

Publish Rate saniyede üretilen event sayısını gösterir. Traffic trendini anlamaya yardımcı olur. Ani düşüş producer problemi olabilir. Ani artış business campaign sonucu olabilir. Capacity planning bu metriği kullanır.

Publish Error Rate

Publish Error Rate başarısız publish oranını gösterir. Broker unavailable veya authorization problemi olabilir. Sıfırın üstündeki her hata aynı severity taşımaz. Retry sonrası başarı ayrıca ölçülmelidir. Kritik event'lerde SLO ile bağlanmalıdır.

Publish Latency

Publish Latency producer'ın broker acknowledgement bekleme süresidir. Network veya broker saturation bunu artırabilir. p50, p95 ve p99 izlenmelidir. Ortalama değer tail latency sorununu gizleyebilir. Deployment etkisi karşılaştırılabilir.

Retry Rate

Retry Rate publisher'ın mesajı yeniden gönderme oranıdır. Yükselmesi görünmeyen altyapı sorununu gösterebilir. Başarılı publish oranı normal görünse bile retry maliyeti artabilir. Duplicate riskini etkiler. Alert trend üzerinden kurulabilir.

Batch Size

Batch Size tek request içinde kaç mesaj gönderildiğini gösterir. Büyük batch throughput'u artırabilir. Latency biraz yükselir. Memory kullanımı etkilenir. Workload için optimal değer test edilmelidir.

Message Size

Message Size network ve storage maliyetini doğrudan etkiler. Ani artış schema değişikliğiyle ilişkili olabilir. Büyük payload broker limitine yaklaşabilir. Percentile dağılımı izlenebilir. Compression oranı ayrıca ölçülebilir.

İzlenmesi Gereken Consumer Metrikleri

Consumer monitoring processing rate, error rate ve latency ile başlamalıdır. Consumer lag veya queue depth işlerin ne kadar geriden geldiğini gösterir. Retry rate geçici dependency sorunlarını görünür kılar. DLQ rate işlenemeyen mesajların oranını ölçer. Bu metrikler tek tek değil, producer traffic ve downstream health ile birlikte yorumlanmalıdır.

Processing Rate

Processing Rate saniyede tamamlanan event sayısını gösterir. Producer rate ile karşılaştırılmalıdır. Düşüş performance regression gösterebilir. Instance bazında distribution önemlidir. Autoscaling kararına girdi olabilir.

Error Rate

Error Rate başarısız message processing oranıdır. Error type ile segment edilmelidir. Validation ve dependency failure ayrılabilir. Deployment sonrası artış alarm üretmelidir. Retry ile maskelenmemelidir.

Processing Latency

Processing Latency tek event'in handler süresini gösterir. p95 ve p99 tail davranışını açıklar. Database yavaşlığı etkileyebilir. Batch processing ayrı ölçülmelidir. SLO event type bazında değişebilir.

Consumer Lag

Consumer Lag bekleyen mesaj miktarını gösterir. Kafka offset farkı olarak ölçülür. Queue sistemlerinde depth benzer sinyaldir. Time lag daha business anlamlı olabilir. Sürekli artış capacity problemi gösterir.

Retry Rate

Retry Rate consumer'ın hata sonrası kaç kez yeniden denediğini gösterir. Geçici incident sırasında artabilir. Kalıcı yüksek oran kötü dependency veya code sorununa işaret eder. Retry storm riski vardır. Error classification ile birlikte incelenmelidir.

DLQ Rate

DLQ Rate terminal failure oranıdır. Sıfıra yakın olması hedeflenebilir. Bazı invalid external data akışlarında normal küçük oran olabilir. Ani artış schema breaking change gösterebilir. Owner'a hızlı alert gitmelidir.

End-to-End Event Latency

End-to-End Event Latency event'in producer tarafından oluşturulmasından consumer processing tamamlanana kadar geçen toplam süredir. Producer timestamp, broker arrival, consumer receive ve completion zamanları bu yolu parçalara ayırır. Bu ölçüm broker gecikmesi ile consumer processing gecikmesini birbirinden ayırmayı kolaylaştırır. p50 normal deneyimi, p95 ve p99 ise tail sorunlarını gösterir. Business SLO'lar çoğu zaman tek handler süresinden çok uçtan uca event latency ile anlam kazanır.

Producer Timestamp

Producer Timestamp event oluşum zamanını taşır. End-to-end sürenin başlangıcıdır. Clock standardı gerekir. Client-generated time her zaman güvenilir olmayabilir. Server-side event time tercih edilebilir.

Broker Arrival

Broker Arrival mesajın broker'a ulaştığı zamanı gösterir. Producer network latency buraya kadar ölçülebilir. Broker metadata her sistemde doğrudan sunulmayabilir. Publish latency ile tahmin yapılabilir. Incident analizinde değerlidir.

Consumer Receive

Consumer Receive event'in handler'a ulaştığı andır. Broker wait time hesaplanabilir. Queue backlog bu süreyi uzatır. Consumer polling interval etkileyebilir. Time lag metriğinin önemli parçasıdır.

Processing Completion

Processing Completion business handler'ın bittiği zamandır. Consumer receive ile fark processing latency verir. Ack veya offset commit biraz daha sonra olabilir. External side effect bu süreye dahil edilebilir. SLO tanımı açık olmalıdır.

p50

p50 median latency değeridir. Event'lerin yarısı bu süreden hızlıdır. Normal deneyimi anlamaya yardımcı olur. Tail problem gizlenebilir. Tek başına kullanılmamalıdır.

p95

p95 event'lerin yüzde 95'inin altında kaldığı latency değeridir. SLO için sık kullanılır. Kullanıcı deneyimindeki gecikmeleri daha iyi gösterir. Peak saatlerde izlenmelidir. Deployment karşılaştırması yapılabilir.

p99

p99 en yavaş yüzde birlik bölümün sınırını gösterir. Queue stall ve retry sorunlarını ortaya çıkarabilir. Çok değişken olabilir. Yüksek traffic sistemlerinde değerlidir. Alert için uygun smoothing gerekebilir.

Async Distributed Tracing

Asenkron distributed tracing HTTP çağrılarından farklıdır çünkü producer ve consumer arasında aynı açık network request bağlantısı bulunmaz. Trace context event metadata içinde taşınmalıdır. W3C Trace Context ve traceparent header bu ilişkiyi standart biçimde kurabilir. OpenTelemetry producer ve consumer span'larını oluşturmak için yaygın bir yaklaşım sunar. Böylece bir kullanıcı isteğinden başlayan akış broker üzerinden geçip downstream consumer'lara kadar tek trace içinde görülebilir.

HTTP Trace ile Event Trace Farkı

HTTP trace parent-child ilişkisini request header üzerinden taşır. Event akışında mesaj broker'da uzun süre bekleyebilir. Consumer farklı zamanda çalışabilir. Span relationship bazen link modeliyle kurulabilir. Processing time ile queue time ayrılmalıdır.

W3C Trace Context

W3C Trace Context trace metadata için standart tanımlar. traceparent temel header'dır. Farklı tracing vendor'ları arasında uyumluluk sağlar. Event metadata içine taşınabilir. Security açısından dış source'tan gelen context doğrulanmalıdır.

traceparent Header

traceparent trace ID ve span ID bilgilerini içerir. Producer mevcut context'i event'e ekler. Consumer bunu okuyup yeni span oluşturur. Context kaybolursa trace zinciri kopar. Messaging library instrumentation otomatik propagation sağlayabilir.

OpenTelemetry

OpenTelemetry vendor-neutral observability standardı sunar. Traces, metrics ve logs için ortak API sağlar. Kafka ve RabbitMQ instrumentation seçenekleri vardır. Custom event metadata için semantic conventions uygulanabilir. Sampling policy yüksek traffic sistemlerde dikkatle seçilmelidir.

Producer Span

Producer Span event publish işlemini temsil eder. Topic ve destination bilgisi attribute olarak eklenebilir. Payload içeriği eklenmemelidir. Publish latency ölçülebilir. Error status broker problemini gösterir.

Consumer Span

Consumer Span event processing süresini temsil eder. Event ID attribute olabilir. Processing result kaydedilebilir. External database çağrıları child span olarak görülür. Retry denemeleri ayrı span veya event olarak işaretlenebilir.

Event-Driven Sistemlerde Loglama

Event-driven loglama yapılandırılmış ve bağlam zengin olmalıdır. Event ID, correlation ID, topic, partition ve offset gibi alanlar incident sırasında arama yapmayı kolaylaştırır. Consumer adı ve processing result hangi handler'ın ne yaptığını gösterir. Payload'ı tamamen loglamak kişisel veri, güvenlik ve maliyet sorunları doğurabilir. Metadata temelli logging çoğu production ihtiyacı için daha güvenli ve sürdürülebilir bir yaklaşımdır.

Event ID

Event ID her log kaydına eklenebilir. Aynı message lifecycle kolay aranır. Producer ve consumer logları bağlanır. Duplicate processing tespit edilebilir. Log formatında standart alan adı kullanılmalıdır.

Correlation ID

Correlation ID business flow içindeki logları birleştirir. HTTP ve event logları birlikte aranabilir. Incident root cause süresi kısalır. Downstream servisler aynı değeri korumalıdır. Privacy açısından kişisel data kullanılmamalıdır.

Topic

Topic adı event'in hangi akıştan geldiğini gösterir. Consumer logunda önemlidir. Environment veya cluster metadata ayrıca eklenebilir. Çok uzun topic adları log maliyetini artırabilir. Structured field olarak saklanmalıdır.

Partition

Partition Kafka debugging için kritiktir. Hot partition sorunları görülebilir. Ordering problemi belirli partition ile ilişkilendirilebilir. Lag incelemesinde yardımcı olur. Offset ile birlikte kaydedilmelidir.

Offset

Offset event'in partition içindeki konumudur. Replay aralığı belirlenebilir. Duplicate delivery analizinde kullanılır. Commit davranışı karşılaştırılabilir. Log retention replay süresiyle uyumlu olmalıdır.

Consumer

Consumer adı veya group ID loglara eklenebilir. Hangi logical handler'ın event'i işlediği görülür. Instance ID gerekirse ayrı alanda tutulur. Deployment version incident analizini kolaylaştırır. Owner mapping catalog üzerinden yapılabilir.

Processing Result

Processing Result success, retry, skipped veya failed gibi değerler taşıyabilir. Duplicate event skipped olarak kaydedilebilir. Business validation ayrı category olabilir. Dashboard log-based metric üretebilir. Result taxonomy standartlaştırılmalıdır.

Payload'ı Tam Loglamanın Riski

Tam payload kişisel veya hassas veri içerebilir. Log retention event retention'dan daha uzun olabilir. Güvenlik erişimi geniş olabilir. Büyük payload log maliyetini artırır. Gerekli alanlar masking ile sınırlı biçimde yazılmalıdır.

PII ve Hassas Verilerin Event'lerde Kullanılması

Event stream'leri uzun retention ve replay özellikleri nedeniyle kişisel veri açısından özel dikkat gerektirir. Data minimization ilkesiyle consumer'ın gerçekten ihtiyaç duymadığı alanlar taşınmamalıdır. Hassas veri encryption, tokenization veya masking yöntemleriyle korunabilir. KVKK ve GDPR kapsamındaki silme talepleri append-only log yapılarında ayrıca planlanmalıdır. Event design review sürecine privacy kontrolü eklemek sonradan yapılacak pahalı veri temizleme çalışmalarını azaltır.

Data Minimization

Event yalnızca gerekli alanları taşımalıdır. Consumer rahatlığı için tüm entity gönderilmemelidir. Hassas data exposure azalır. Payload boyutu küçülür. Schema değişim alanı da daralır.

Event Retention

Retention kişisel verinin ne kadar süre saklandığını belirler. İş ihtiyacı kadar tutulmalıdır. Gereksiz uzun süre risk oluşturur. Backup retention ayrıca değerlendirilmelidir. Compliance policy ile eşleştirilmelidir.

Encryption

TLS data in transit koruması sağlar. Disk encryption data at rest için kullanılabilir. Field-level encryption bazı hassas alanlarda gerekebilir. Key management ayrı güvenlik sorumluluğudur. Consumer erişim yetkisi sınırlandırılmalıdır.

Tokenization

Tokenization hassas değeri temsil eden anlamsız token kullanır. Gerçek data ayrı güvenli store'da tutulabilir. Event içindeki exposure azalır. Consumer gerektiğinde yetkili çözümleme yapar. Latency ve dependency maliyeti değerlendirilmelidir.

Masking

Masking verinin yalnızca gerekli kısmını görünür bırakır. Log ve monitoring ekranlarında faydalıdır. Event payload için de bazı kullanım durumları olabilir. Geri döndürülemez masking tercih edilebilir. Business ihtiyacı korunmalıdır.

KVKK/GDPR Silme Talepleri

Silme talepleri immutable event log'larda zorlayıcı olabilir. Kişisel data event'e hiç koymamak güçlü önlemdir. Tokenization silmeyi merkezi store'a indirebilir. Crypto-shredding bazı tasarımlarda kullanılabilir. Hukuki gereksinimler uzman değerlendirmesiyle ele alınmalıdır.

Replay Edilebilir Loglarda Kişisel Veri Riski

Replay log'u eski kişisel veriyi yeniden consumer'lara taşıyabilir. Silinmiş data yeniden projection'a dönebilir. Tombstone veya deletion event'leri doğru sırada işlenmelidir. Replay tooling privacy state'i gözetmelidir. Test senaryoları silme sonrası replay davranışını kapsamalıdır.

Message Broker Güvenliği

Message broker güvenliği network şifrelemesi, kimlik doğrulama ve yetkilendirme katmanlarından oluşur. TLS trafik gizliliği sağlar. mTLS servis kimliğini karşılıklı doğrulamaya yardımcı olur. SASL veya benzeri authentication mekanizmaları producer ve consumer kimliğini belirler. ACL ve topic-level authorization least privilege ilkesine göre yalnızca gerekli event akışlarına erişim vermelidir.

TLS

TLS producer, broker ve consumer trafiğini şifreler. Network sniffing riskini azaltır. Sertifika lifecycle yönetimi gerekir. Expiration alarmı kurulmalıdır. Güçlü cipher policy kullanılmalıdır.

mTLS

mTLS hem client hem server sertifikasını doğrular. Service identity güçlenir. Sertifika rotasyonu otomatikleştirilmelidir. Private key güvenli saklanmalıdır. Authorization yine ayrı ACL ile yapılmalıdır.

SASL

SASL Kafka gibi platformlarda authentication için kullanılabilir. Farklı mechanism seçenekleri vardır. Credential rotation planı gereklidir. Shared account kullanımından kaçınılmalıdır. Per-service identity audit kalitesini artırır.

ACL

ACL hangi identity'nin hangi kaynağa erişebileceğini belirler. Producer yalnızca gerekli topic'e write yapmalıdır. Consumer yalnızca ilgili topic'i read etmelidir. Admin permission sınırlı tutulmalıdır. Değişiklikler audit edilmelidir.

Topic-Level Authorization

Topic-Level Authorization domain isolation sağlar. Payment event'leri herkese açık olmamalıdır. Consumer catalog yetki taleplerini destekleyebilir. Wildcard ACL dikkatle kullanılmalıdır. Cross-domain access review süreci olmalıdır.

Least Privilege

Least Privilege servislerin yalnızca ihtiyaç duyduğu yetkiye sahip olmasıdır. Broad read-write permission güvenlik riskidir. Environment ayrımı uygulanmalıdır. Credential compromise etkisi sınırlanır. Permission review düzenli yapılmalıdır.

Multi-Tenant Event-Driven Sistemler

Multi-tenant event-driven sistemlerde tenant kimliği veri izolasyonu ve kapasite yönetimi açısından kritik rol oynar. Shared topic operasyonu sadeleştirirken consumer'ın tenant filter kurallarına güvenmesini gerektirir. Tenant başına topic güçlü izolasyon sağlayabilir ancak topic sayısını ciddi biçimde artırabilir. ACL ve data isolation modeli business güvenlik ihtiyacına göre tasarlanmalıdır. Büyük tenant'ların diğerlerini etkilememesi için Noisy Neighbor riski kapasite planında ayrıca ele alınmalıdır.

Tenant ID

Tenant ID event'in hangi müşteriye ait olduğunu belirtir. Metadata veya payload içinde taşınabilir. Authorization policy ile doğrulanmalıdır. Loglarda hassas identifier kullanımı değerlendirilmelidir. Partition key olarak kullanıldığında distribution etkilenir.

Shared Topic

Shared Topic birden fazla tenant event'ini aynı topic'te tutar. Operasyon daha sadedir. Consumer filtering hatası data leak riski doğurabilir. ACL topic seviyesinde tenant izolasyonu sağlayamaz. Application-level authorization güçlü olmalıdır.

Tenant Başına Topic

Her tenant için ayrı topic güçlü isolation sunabilir. Retention ve ACL bağımsız yönetilebilir. Çok sayıda tenant varsa topic explosion oluşur. Platform automation gerekir. Küçük tenant sayılı enterprise sistemlerde uygulanabilir.

ACL

ACL tenant veya servis erişimini sınırlar. Shared topic modelinde daha kaba granularity olabilir. Separate topic daha detaylı kontrol sunar. Permission lifecycle tenant offboarding ile birlikte yönetilmelidir. Audit log zorunlu olabilir.

Data Isolation

Data Isolation tenant verisinin diğer tenant tarafından görülememesini sağlar. Broker, consumer ve storage katmanları birlikte değerlendirilmelidir. Misconfigured consumer ciddi güvenlik sorunu yaratabilir. Encryption key tenant bazında ayrılabilir. Testler cross-tenant access senaryosu içermelidir.

Noisy Neighbor

Noisy Neighbor bir tenant'ın aşırı trafiğinin diğer tenant'ları etkilemesidir. Shared partition hot spot oluşturabilir. Rate limit tenant bazında uygulanabilir. Dedicated resource büyük müşteriler için düşünülebilir. SLO tenant segmentine göre izlenebilir.

Event-Driven Sistemleri Nasıl Test Ederiz?

Event-driven sistem testleri yalnızca consumer unit testlerinden ibaret değildir. Producer contract, serialization, broker davranışı ve consumer side effect birlikte doğrulanmalıdır. Schema testleri breaking değişiklikleri erken yakalar. Integration ve end-to-end testler gerçek mesaj akışını çalıştırır. Duplicate, out-of-order ve broker failure gibi failure senaryoları test edilmeden production güvenilirliği konusunda güçlü bir güvence elde edilemez.

Unit Tests

Unit Tests handler business logic'ini hızlı doğrular. Broker bağımlılığı mock edilebilir. Idempotency kararları test edilebilir. Error classification kontrol edilir. Ancak gerçek serialization davranışını göstermez.

Producer Tests

Producer Tests doğru event type üretildiğini doğrular. Metadata alanları kontrol edilir. Schema validation yapılır. Outbox insert transaction davranışı test edilir. Publish abstraction failure senaryosu kapsanır.

Consumer Tests

Consumer Tests event'i doğru deserialize ettiğini doğrular. Business side effect kontrol edilir. Duplicate event davranışı test edilir. Retryable ve non-retryable hata ayrımı sınanır. Ack veya commit stratejisi integration testte doğrulanmalıdır.

Schema Tests

Schema Tests contract yapısını kontrol eder. Required field değişiklikleri tespit edilir. Compatibility rule çalıştırılır. Sample payload validation yapılabilir. Registry entegrasyonu CI içinde test edilir.

Integration Tests

Integration Tests gerçek broker ve database ile çalışabilir. Testcontainers bu amaçla kullanışlıdır. Serialization ve routing doğrulanır. Consumer retry davranışı gözlemlenir. Network ve container start maliyeti unit testten yüksektir.

End-to-End Tests

End-to-End Tests producer'dan final side effect'e kadar akışı doğrular. Gerçek servisler veya staging environment kullanılabilir. Correlation ID ile sonuç izlenebilir. Flaky testlerden kaçınmak için deterministic assertion gerekir. Az sayıda kritik flow seçilmelidir.

Testcontainers ile Broker Testleri

Testcontainers entegrasyon testlerinde gerçek Kafka, RabbitMQ ve Schema Registry instance'larını container içinde başlatmayı kolaylaştırır. Böylece mock broker yerine gerçek protocol ve serialization davranışı test edilir. Consumer group, acknowledgement veya routing gibi detaylar daha güvenilir biçimde doğrulanır. CI ortamında test isolation güçlenir. Test süresini kontrol etmek için container lifecycle ve shared fixture stratejisi dikkatle tasarlanmalıdır.

Kafka Container

Kafka Container integration test için gerçek broker sağlar. Topic oluşturulabilir. Producer ve consumer gerçek client kullanır. Offset commit davranışı test edilir. Container start süresi suite tasarımını etkiler.

RabbitMQ Container

RabbitMQ Container exchange ve queue topology'sini test etmeyi sağlar. Binding ve routing key doğrulanabilir. Manual ack davranışı çalıştırılabilir. DLQ akışı test edilir. Management API gerektiğinde kullanılabilir.

Schema Registry

Schema Registry container compatibility test için kullanılabilir. Producer schema publish edebilir. Consumer generated type doğrulayabilir. Breaking schema testi yapılabilir. CI ile production davranışı arasındaki fark azalır.

Gerçek Serialization

Gerçek serializer runtime kütüphanesi kullanılır. JSON naming farkları ortaya çıkar. Avro schema ID davranışı doğrulanır. Protocol Buffers compatibility test edilir. Mock testlerin kaçırdığı sorunlar yakalanır.

Gerçek Consumer/Producer Davranışı

Gerçek client batching ve retry yapar. Rebalance test edilebilir. Publisher confirm doğrulanabilir. Ack timeout davranışı görülebilir. Production bug'larının önemli kısmı bu seviyede yakalanabilir.

Event Contract Testing

Event Contract Testing producer'ın yayınladığı mesaj ile consumer'ın beklediği contract'ın uyumunu doğrular. Producer contract schema ve semantiği tanımlar. Consumer contract kullanılan alanları ve beklentileri görünür kılar. Compatibility kontrolleri teknik breaking change'leri yakalar. Consumer-driven contract yaklaşımı özellikle çok sayıda bağımsız consumer bulunduğunda değişiklik etkisini erken görmeye yardımcı olabilir.

Producer Contract

Producer Contract event'in publish ettiği schema'yı tanımlar. Metadata ve payload alanları bulunur. Example event test fixture olarak kullanılabilir. Registry ile versionlanır. Business semantik dokümantasyonu ayrıca gerekir.

Consumer Contract

Consumer Contract hangi field'ları kullandığını gösterir. Optional alan davranışı test edilir. Event type beklentisi doğrulanır. Producer değişikliği consumer testlerini bozabilir. Ownership görünür olmalıdır.

Schema Compatibility

Schema Compatibility version'ların teknik uyumunu kontrol eder. Backward veya full policy kullanılabilir. CI automation breaking change'i engeller. Semantik değişiklik yine review gerektirir. Aynı field'ın anlamını değiştirmek schema tarafından yakalanmayabilir.

Breaking Event Change

Breaking Change eski consumer'ın çalışmasını engeller. Field delete veya type change örnektir. Yeni event version gerekebilir. Migration planı hazırlanmalıdır. Consumer owner'lar bilgilendirilmelidir.

Consumer-Driven Contract

Consumer-Driven Contract consumer beklentilerini producer'a geri bildirir. Producer yalnızca gerçekten kullanılan alanları görebilir. Contract test platformu entegrasyonu kolaylaştırır. Çok sayıda consumer olduğunda governance gerekir. Tek gerçek kaynak schema catalog ile uyumlu tutulmalıdır.

Failure Scenario Testleri

Failure Scenario testleri event-driven sistemlerin gerçek dayanıklılığını ortaya çıkarır. Duplicate event, out-of-order event ve consumer crash normal çalışma kadar önemlidir. Broker unavailable veya slow consumer durumları backpressure davranışını gösterir. Invalid payload ve DLQ akışı operasyon planının doğruluğunu test eder. Replay testi ise recovery stratejisinin production öncesinde gerçekten çalışıp çalışmadığını kanıtlar.

Duplicate Event

Aynı event iki kez gönderilir. Business side effect sayısı kontrol edilir. Database state değişmemelidir. Processed event kaydı doğrulanır. Consumer başarılı ack vermelidir.

Out-of-Order Event

Version 2 event version 1'den önce gönderilir. Consumer davranışı gözlemlenir. Buffer veya ignore policy doğrulanır. Final state beklenen değer olmalıdır. Metric veya log kaydı kontrol edilir.

Consumer Crash

Consumer processing ortasında zorla durdurulur. Mesajın yeniden teslim edilmesi beklenir. Duplicate side effect oluşmamalıdır. Offset veya ack davranışı doğrulanır. Restart sonrası recovery ölçülür.

Broker Unavailable

Broker test sırasında kapatılır. Producer retry davranışı gözlemlenir. Outbox event kaybolmamalıdır. Consumer reconnect edebilmelidir. Recovery sonrası backlog işlenmelidir.

Invalid Payload

Schema dışı payload gönderilir. Consumer sonsuz retry yapmamalıdır. DLQ'ya geçiş doğrulanır. Error metadata kontrol edilir. Alert mekanizması test edilebilir.

Slow Consumer

Handler yapay olarak yavaşlatılır. Queue depth veya lag artışı ölçülür. Autoscaling davranışı gözlemlenir. Downstream saturation kontrol edilir. Alarm threshold doğrulanır.

DLQ

Poison message maksimum retry'ı aşar. DLQ'ya gönderilmesi beklenir. Original payload ve metadata kontrol edilir. Replay tooling test edilir. Audit trail doğrulanır.

Replay

Geçmiş event aralığı tekrar işlenir. Duplicate side effect oluşmamalıdır. Projection beklenen state'e gelmelidir. External call suppression doğrulanır. Replay throughput production kapasitesini aşmamalıdır.

Idempotency Nasıl Test Edilir?

Idempotency testi teorik kontrol yerine aynı event'in gerçekten birden fazla kez gönderilmesiyle yapılmalıdır. Business side effect sayısı bir kez kalmalıdır. Database final state iki işleme rağmen değişmemelidir. Processed event kaydı duplicate mesajın tanındığını göstermelidir. Bu test consumer restart ve paralel delivery senaryolarıyla genişletildiğinde daha gerçekçi sonuç verir.

Aynı Event'i İki Kez Gönder

Test aynı event ID ile iki mesaj yayınlar. Consumer ikisini de alabilir. İlk mesaj business operation'ı çalıştırır. İkinci mesaj duplicate olarak tanınmalıdır. Final state değişmemelidir.

Business Side Effect'i Say

E-posta veya payment mock call count ölçülebilir. Beklenen değer birdir. Duplicate message ikinci çağrı üretmemelidir. Metric de aynı sonucu gösterebilir. External idempotency key doğrulanabilir.

Database State'i Doğrula

Database row sayısı kontrol edilir. Balance iki kez artmamalıdır. Unique constraint aktif olmalıdır. Transaction rollback test edilebilir. Final state business expectation ile eşleşmelidir.

Processed Event Kaydını Kontrol Et

ProcessedMessages tablosunda tek kayıt bulunmalıdır. Event ID doğru olmalıdır. Consumer name scope'u doğrulanır. Duplicate insert unique constraint'e takılabilir. Hata yerine başarılı skip davranışı beklenir.

Event Ordering Nasıl Test Edilir?

Event ordering testi aynı key'e ait ardışık event'leri kontrollü biçimde yayınlayarak yapılır. Paralel producer kullanımı partition assignment davranışını gerçekçi hâle getirir. Consumer restart ve retry ordering üzerindeki etkileri ortaya çıkarır. Final state yalnızca mesaj alım sırasına değil business version kurallarına göre doğrulanmalıdır. Bu test özellikle balance, stock ve workflow state gibi sıraya duyarlı sistemlerde kritik önem taşır.

Aynı Key ile Ardışık Event'ler

Aynı aggregate ID için birkaç event yayınlanır. Hepsi aynı partition'a gitmelidir. Consumer beklenen sırada almalıdır. Offset artışı kontrol edilir. Final state sequence ile doğrulanır.

Paralel Producer

Birden fazla producer aynı key için event gönderebilir. Producer ordering configuration test edilir. Concurrent command race ortaya çıkarılabilir. Aggregate version conflict görülebilir. Business serialization gerekebilir.

Consumer Restart

Consumer processing sırasında restart edilir. Partition rebalance oluşur. Son commit edilen offset'ten devam edilir. Duplicate event görülebilir. Final ordering state korunmalıdır.

Retry

Ortadaki event bilerek hata verir. Retry sırasında sonraki event'in davranışı gözlemlenir. Partition blocking veya retry topic etkisi değerlendirilir. Out-of-order risk doğrulanır. Policy business requirement ile karşılaştırılır.

Beklenen Final State

Test sonunda aggregate state kontrol edilir. Event sayısı tek başına yeterli değildir. Version beklenen değerde olmalıdır. Side effect sırası gerekirse doğrulanır. Test deterministic sonuç üretmelidir.

CI/CD'de Event-Driven Quality Gates

Event-driven quality gates kodun production'a çıkmadan önce contract, reliability ve security açısından kontrol edilmesini sağlar. Unit tests temel business logic'i doğrular. Schema compatibility ve contract tests entegrasyon risklerini azaltır. Integration tests gerçek broker davranışını çalıştırır. Security scan ve performance test ile birlikte breaking event değişikliklerini engelleyen otomatik gate güvenilir deployment kültürü oluşturur.

Unit Tests

Unit Tests her commit'te hızlı çalışmalıdır. Handler behavior kontrol edilir. Error classification doğrulanır. Event mapping test edilir. Failure hızlı geri bildirim sağlar.

Schema Compatibility

Pipeline yeni schema'yı mevcut version ile karşılaştırır. Breaking change merge'i durdurur. Policy event type bazında uygulanabilir. Override sınırlı yetki ister. Migration planı zorunlu tutulabilir.

Contract Tests

Producer ve consumer contract'ları test edilir. Sample event gerçek serializer ile oluşturulur. Consumer expectation doğrulanır. Contract artifact versionlanabilir. Failure deployment öncesinde görülür.

Integration Tests

Gerçek broker container ile test edilir. Routing ve ack behavior doğrulanır. Database transaction birlikte çalıştırılır. Outbox relay testi yapılabilir. Suite süresi kontrol altında tutulmalıdır.

Security Scan

Dependency vulnerability scan çalıştırılabilir. Secret detection yapılmalıdır. Broker ACL configuration policy kontrol edilebilir. Container image taranabilir. Critical finding deployment'ı durdurabilir.

Performance Test

Performance Test producer ve consumer throughput'unu ölçer. Peak traffic simüle edilir. Lag growth gözlemlenir. Message size ve batch etkisi incelenir. Capacity regression deployment öncesinde yakalanabilir.

Breaking Event Değişikliklerini Engellemek

Schema gate otomatik bariyer sağlar. Field type değişikliği tespit edilir. Required field ekleme engellenebilir. Consumer catalog impact gösterir. Approved migration olmadan production publish yapılmamalıdır.

Consumer Deployment Sırasında Ne Olur?

Consumer deployment yalnızca process restart değildir. Graceful shutdown yapılmazsa in-flight message yarıda kalabilir. Offset commit veya acknowledgement zamanlaması duplicate processing davranışını belirler. Kafka consumer group deployment sırasında rebalance yaşayabilir. Bu nedenle deployment senaryoları idempotency, redelivery ve startup health check ile birlikte tasarlanmalıdır.

Graceful Shutdown

Graceful Shutdown yeni mesaj alımını durdurur. Devam eden processing tamamlanır. Ack veya offset commit yapılır. Belirli timeout uygulanır. Ardından process kapanır.

In-Flight Message

In-Flight Message consumer'ın o anda işlediği mesajdır. Deployment sırasında kaybedilmemelidir. Processing tamamlanmadan process kill edilirse redelivery olabilir. Side effect tamamlanmış olabilir. Idempotency duplicate riskini yönetir.

Offset Commit

Kafka consumer processing sonrası offset commit eder. Shutdown sırasında pending commit tamamlanmalıdır. Commit başarısız olabilir. Mesaj yeniden okunabilir. At-least-once tasarım bunu kabul eder.

Redelivery

Unacked veya uncommitted message yeniden teslim edilir. Deployment sırasında bu normal olabilir. Error metric olarak yanlış sayılmamalıdır. Duplicate event güvenli işlenmelidir. Deployment sonrası kısa spike gözlemlenebilir.

Consumer Group Rebalance

Kafka consumer ayrıldığında partition'lar yeniden atanır. Yeni instance katıldığında da rebalance olabilir. Processing kısa süre durabilir. Cooperative rebalancing etkiyi azaltabilir. Rebalance rate metric olarak izlenebilir.

Duplicate Processing

Deployment sırasında duplicate processing ihtimali artabilir. Ack öncesi restart bunun tipik nedenidir. Consumer event ID kontrol etmelidir. Business side effect korunmalıdır. Test ortamında rolling deployment senaryosu çalıştırılmalıdır.

Kafka Consumer Rebalancing

Kafka consumer rebalancing consumer group üyeliği değiştiğinde partition'ların yeniden dağıtılmasıdır. Yeni consumer gruba katıldığında veya mevcut consumer ayrıldığında assignment değişebilir. Bazı rebalancing türlerinde processing kısa süre tamamen durabilir. Cooperative rebalancing daha kademeli hareket ederek bu etkiyi azaltmayı hedefler. Deployment ve autoscaling stratejisi rebalance sıklığını gereksiz artırmamalıdır.

Consumer Gruba Katılırsa

Yeni consumer group coordinator tarafından fark edilir. Partition assignment yeniden hesaplanabilir. Mevcut consumer'lar bazı partition'ları bırakır. Yeni instance workload alır. Kısa latency artışı olabilir.

Consumer Ayrılırsa

Consumer graceful leave veya timeout ile gruptan çıkar. Sahip olduğu partition'lar yeniden atanır. Uncommitted mesajlar tekrar işlenebilir. Lag geçici artabilir. Idempotency korunmalıdır.

Partition Reassignment

Reassignment partition ownership'in consumer'lar arasında değişmesidir. Commit edilen offset yeni owner tarafından kullanılır. State store kullanan uygulamalarda restore gerekebilir. Çok sık olması throughput'u düşürür. Monitoring yapılmalıdır.

Stop-the-World Etkisi

Bazı rebalance türlerinde tüm group processing durabilir. Büyük consumer group'larda etki daha belirgindir. Deployment sırasında latency spike oluşur. Session timeout tuning önemlidir. Cooperative model yardımcı olabilir.

Cooperative Rebalancing

Cooperative Rebalancing partition hareketlerini daha kademeli yapmayı hedefler. Tüm consumer'ların aynı anda durmasını azaltır. Client compatibility kontrol edilmelidir. Incremental assignment kullanılır. Gerçek workload ile deployment testi yapılmalıdır.

Event-Driven Sistemlerde Capacity Planning

Capacity planning event rate, event boyutu, retention ve replication gibi değerlerin birlikte hesaplanmasını gerektirir. Ortalama Events per Second tek başına yeterli değildir, peak traffic de modellenmelidir. Consumer throughput producer peak hızını sürdürülebilir biçimde karşılamalıdır. Storage growth retention ve replication factor ile doğrudan artar. Kapasite planı gerçek production benzeri load test ile doğrulanmalıdır.

Events per Second

EPS sistem throughput ihtiyacını gösterir. Ortalama ve peak ayrı ölçülmelidir. Event type bazında dağılım faydalıdır. Growth tahmini eklenmelidir. Broker ve consumer sizing buna dayanır.

Ortalama Event Boyutu

Event boyutu network ve disk hesaplarında kullanılır. Ortalama değer tek başına yeterli değildir. p95 message size da izlenmelidir. Schema growth tahmin edilmelidir. Compression etkisi ölçülebilir.

Peak Traffic

Peak Traffic kampanya veya toplu job sırasında oluşabilir. Ortalama kapasitenin birkaç katı olabilir. Broker kısa süre buffer sağlayabilir. Consumer backlog'u kabul edilebilir sürede kapatmalıdır. Peak load test yapılmalıdır.

Retention

Retention storage ihtiyacını doğrudan etkiler. Uzun retention replay avantajı sağlar. Disk maliyeti artar. Compliance gereksinimi sınır koyabilir. Topic bazında farklı retention uygulanabilir.

Replication Factor

Replication Factor her partition'ın kaç kopya tutulacağını belirler. Dayanıklılık artar. Storage ihtiyacı katlanır. Network replication trafiği oluşur. Zone dağılımı planlanmalıdır.

Consumer Throughput

Consumer Throughput sürdürülebilir işleme hızıdır. Peak producer rate ile karşılaştırılmalıdır. Downstream latency sınır getirir. Concurrency tuning yapılabilir. Scaling limitleri bilinmelidir.

Storage Growth

Storage Growth EPS, message size ve retention'dan hesaplanabilir. Replication factor ile çarpılır. Compaction davranışı ayrıca etkiler. Safety margin bırakılmalıdır. Disk alarmı capacity planına bağlanmalıdır.

Event Payload Boyutu Ne Kadar Olmalı?

Event payload için her sistemde geçerli tek bir ideal boyut yoktur. Broker limitleri ve network maliyeti üst sınırı etkiler. Büyük event'ler serialization, storage ve replay sürelerini artırır. Compression bazı durumlarda fayda sağlar ancak gereksiz veriyi taşımak için bahane olmamalıdır. Büyük dosyaları event içine koymak yerine object storage üzerinde saklayıp event içinde güvenli bir reference taşımak çoğu zaman daha doğru tasarımdır.

Broker Limitleri

Her broker maksimum message size sınırına sahiptir. Configuration ile artırılabilir. Büyük değer memory ve network etkisi yaratır. Producer ve consumer limitleri uyumlu olmalıdır. Limit aşımı deployment öncesinde test edilmelidir.

Büyük Event'lerin Maliyeti

Büyük payload daha fazla network bandwidth kullanır. Broker disk tüketimi artar. Consumer memory pressure yaşayabilir. Retry trafiği daha pahalı olur. Replay süresi uzar.

Compression

Compression network ve storage kullanımını azaltabilir. CPU maliyeti ekler. JSON benzeri tekrar eden veri iyi sıkışabilir. Batch compression daha etkili olabilir. Latency ve throughput birlikte benchmark edilmelidir.

Büyük Dosyayı Broker'a Koymak

Video veya büyük PDF gibi dosyalar broker için uygun değildir. Message size limitleri zorlanır. Retry maliyeti artar. Broker storage gereksiz dolar. Dosya object storage'a koyulmalıdır.

Object Storage Reference Pattern

Dosya object storage üzerinde saklanır. Event yalnızca object key veya güvenli URL reference taşır. Consumer gerektiğinde dosyayı indirir. Access control uygulanmalıdır. Lifecycle policy event retention ile uyumlu olmalıdır.

Event Batching

Event batching birden fazla mesajı tek network veya processing operasyonunda ele alarak throughput'u artırabilir. Producer batch broker'a daha az request gönderir. Consumer batch database bulk operation ile verim kazanabilir. Bunun karşılığında tek mesajın bekleme süresi artabilir. Batch içindeki tek failure'ın tüm batch'i mi yoksa yalnızca ilgili event'i mi etkileyeceği açık biçimde tasarlanmalıdır.

Producer Batch

Producer kısa süre mesajları buffer içinde toplar. Tek request ile broker'a gönderir. Network overhead azalır. Latency biraz artabilir. Batch size ve linger ayarları test edilmelidir.

Consumer Batch

Consumer birden fazla event'i birlikte işleyebilir. Database bulk insert yapılabilir. Throughput artar. Bir event failure olduğunda retry granularity zorlaşır. Ordering requirement dikkate alınmalıdır.

Throughput Kazancı

Batching request başına overhead'i azaltır. Serialization ve network daha verimli kullanılabilir. Database round-trip sayısı düşer. Yüksek hacimde belirgin avantaj sağlar. Düşük trafikte etkisi sınırlı olabilir.

Latency Maliyeti

Batch dolmasını beklemek mesaj latency'sini artırır. Real-time flow için büyük batch uygun olmayabilir. Maximum wait time belirlenir. p95 latency izlenmelidir. Throughput hedefi kullanıcı beklentisiyle dengelenmelidir.

Failure Granularity

Batch içinde tek event invalid olabilir. Tüm batch retry edilirse başarılı event'ler duplicate olur. Per-item result faydalıdır. Transaction boundary belirlenmelidir. DLQ mesaj seviyesinde çalışmalıdır.

Broker High Availability

Broker high availability messaging altyapısının tek node arızasında çalışmaya devam etmesini amaçlar. Replication mesaj verisinin birden fazla node üzerinde bulunmasını sağlar. Quorum yaklaşımı leader seçimi ve veri güvenliği için kullanılabilir. Zone failure senaryosu yalnızca broker değil network ve storage bağımlılıklarıyla birlikte test edilmelidir. Producer ve consumer client'larının failover sırasında reconnect ve retry davranışı da HA tasarımının parçasıdır.

Replication

Replication event verisini birden fazla broker'da tutar. Tek node kaybında data korunur. Replication lag izlenmelidir. Storage maliyeti artar. Failure domain dağılımı önemlidir.

Quorum

Quorum çoğunluk üzerinden karar verilmesini sağlar. Split-brain riskini azaltır. Yeterli node kaybında availability düşebilir. Cluster size buna göre seçilmelidir. Network partition test edilmelidir.

Broker Failure

Tek broker kapandığında leader değişebilir. Producer kısa süre hata alabilir. Client metadata refresh yapmalıdır. Consumer rebalance olabilir. SLO failover süresini kapsamalıdır.

Zone Failure

Bir availability zone tamamen kaybolabilir. Replica'lar farklı zone'lara dağıtılmalıdır. Network dependency değerlendirilmeli. Quorum hâlâ sağlanmalıdır. Chaos test ile doğrulanabilir.

Producer/Consumer Failover

Client birden fazla broker adresi bilmelidir. Connection failure sonrası otomatik reconnect olabilir. Retry duplicate publish ihtimali yaratabilir. Consumer tekrar teslim alabilir. Idempotency HA senaryolarında da gereklidir.

Multi-Region Event-Driven Architecture

Multi-region event-driven architecture düşük latency, disaster recovery veya data residency ihtiyaçları için kullanılabilir. Region replication event'lerin farklı coğrafyalara taşınmasını sağlar. Active-active model yüksek availability sunarken duplicate event, ordering ve conflict resolution sorunlarını artırır. Active-passive model daha sade olabilir fakat failover süresi vardır. Region tasarımı business RPO ve RTO hedeflerine göre seçilmelidir.

Region Replication

Event'ler region'lar arasında replicate edilebilir. Asenkron replication gecikme oluşturur. Duplicate veya loop önlenmelidir. Replication lag metric olarak izlenmelidir. Bandwidth maliyeti hesaplanmalıdır.

Active-Active

Active-Active birden fazla region'ın aynı anda trafik almasıdır. Availability yüksektir. Aynı entity iki region'da güncellenebilir. Conflict resolution gerekir. Global ordering daha zordur.

Active-Passive

Active-Passive bir region'ın ana, diğerinin standby olmasıdır. Write conflict daha azdır. Failover prosedürü gerekir. Replica freshness RPO'yu etkiler. Düzenli DR drill yapılmalıdır.

Duplicate Events

Cross-region replication duplicate event üretebilir. Event ID global uniqueness sağlamalıdır. Consumer deduplication region bağımsız olmalıdır. Replay duplicate riskini artırabilir. Metadata source region taşıyabilir.

Ordering

Region'lar arası global ordering pahalıdır. Network latency farklıdır. Aggregate home region yaklaşımı kullanılabilir. Sequence number yardımcı olur. Business requirement dar tutulmalıdır.

Conflict Resolution

Active-active state conflict üretilebilir. Last-write-wins her business için doğru değildir. Domain-specific merge gerekebilir. Compensation uygulanabilir. Conflict audit edilmelidir.

Data Residency

Bazı veriler belirli bölgede kalmak zorunda olabilir. Event replication privacy policy ile sınırlandırılmalıdır. Tenant bazlı routing gerekebilir. Payload minimization önemlidir. Legal gereksinimler mimari karara dahil edilmelidir.

Disaster Recovery

Disaster Recovery event-driven sistemde yalnızca broker backup almak değildir. RPO kabul edilebilir veri kaybı miktarını, RTO ise hizmetin ne kadar sürede geri dönmesi gerektiğini belirler. Broker replication ve backup stratejisi bu hedefleri desteklemelidir. Consumer offset ve Schema Registry recovery unutulmamalıdır. Replay planı felaket sonrası consumer state'in yeniden oluşturulabilmesi için önceden hazırlanmalı ve düzenli olarak test edilmelidir.

RPO

RPO kabul edilebilir veri kaybı penceresidir. Sıfıra yakın hedef daha pahalıdır. Replication tasarımını etkiler. Event criticality belirleyicidir. Business owner ile kararlaştırılmalıdır.

RTO

RTO sistemin ne kadar sürede geri dönmesi gerektiğini belirtir. Failover automation bu süreyi azaltır. Broker dışında consumer ve dependency'ler de kapsama dahildir. Runbook hazırlanmalıdır. DR drill gerçek süreyi ölçmelidir.

Broker Backup

Backup broker verisini uzun süreli recovery için koruyabilir. Snapshot consistency önemlidir. Restore süresi RTO'yu etkiler. Backup tek başına HA değildir. Düzenli restore testi yapılmalıdır.

Replication

Replication yakın zamanlı data kopyası sağlar. Zone veya region seviyesinde olabilir. Aynı corruption replicate olabilir. Backup ile birlikte kullanılması gerekir. Lag RPO üzerinde etkilidir.

Consumer Offset Recovery

Offset kaybı consumer'ın nereden devam edeceğini belirsizleştirir. Offset backup veya replicated metadata korunmalıdır. En kötü durumda replay yapılabilir. Idempotent consumer recovery riskini azaltır. Starting offset policy dokümante edilmelidir.

Schema Registry Recovery

Schema Registry event decoding için kritik olabilir. Schema ID mapping korunmalıdır. Backup alınmalıdır. Restore sırası broker ve consumer ile koordine edilmelidir. Registry kaybı consumer startup'ını engelleyebilir.

Replay Planı

Replay Plan hangi topic ve offset aralığının yeniden işleneceğini tanımlar. Side effect suppression adımları yazılmalıdır. Rate limit belirlenir. Owner ve onay süreci bulunur. Plan düzenli test edilmelidir.

Event-Driven Architecture Anti-Pattern'leri

Event-driven mimaride en yaygın hata her problemi event ile çözmeye çalışmaktır. Command'i event diye adlandırmak sistem semantiğini bozar. Global ordering beklemek ölçeklenebilirliği gereksiz sınırlar. Consumer'ın duplicate mesaj almayacağını varsaymak production failure'larını kaçınılmaz hâle getirir. Retry, DLQ, schema governance ve ownership süreçleri yoksa broker eklemek sistemi daha güvenilir değil, yalnızca daha zor izlenir hâle getirebilir.

Her Şeyi Event Yapmak

Her servis çağrısı asenkron olmak zorunda değildir. Kullanıcı anında cevap bekleyebilir. Basit query HTTP ile daha doğal olabilir. Event kullanmak yeni failure mode getirir. Teknoloji değil business need belirleyici olmalıdır.

Command'i Event Diye Adlandırmak

SendEmailRequested ile EmailSent aynı anlamı taşımaz. İlki niyet veya command niteliğindedir. İkincisi gerçekleşmiş event'tir. İsimler karıştığında retry semantiği bozulabilir. Naming review yapılmalıdır.

Global Ordering Beklemek

Tüm event'leri tek sıra yapmak throughput'u sınırlar. Çoğu business yalnızca aggregate ordering ister. Partition key ile dar scope sağlanabilir. Global sequence merkezi bottleneck yaratır. Gereksinim sorgulanmalıdır.

Consumer'ın Duplicate Almayacağını Varsaymak

Network failure duplicate delivery üretebilir. Broker retry yapabilir. Consumer crash sonrası mesaj tekrar gelir. Idempotency olmadan side effect çoğalır. Duplicate testi zorunlu olmalıdır.

Retry'ı Sonsuza Kadar Yapmak

Poison message sonsuz retry ile consumer'ı meşgul eder. Queue lag büyür. Downstream sürekli yük alır. Maximum attempt belirlenmelidir. DLQ ve investigation süreci kullanılmalıdır.

DLQ Oluşturup Hiç İşletmemek

DLQ yalnızca storage değildir. Owner olmalıdır. Alert kurulmalıdır. Replay tooling bulunmalıdır. Düzenli review yapılmalıdır.

Schema'sız JSON Event'ler

Serbest JSON kısa vadede hızlı görünür. Zamanla consumer beklentileri belirsizleşir. Field type değişiklikleri incident üretir. JSON Schema veya başka contract kullanılmalıdır. Compatibility CI içinde kontrol edilmelidir.

Producer Database'ini Consumer'a Açmak

Consumer producer database'ine doğrudan bağlanmamalıdır. Internal schema coupling oluşur. Producer migration zorlaşır. Security sınırı bozulur. Event veya API contract kullanılmalıdır.

Broker'ı Distributed Database Gibi Kullanmak

Broker her sorgu ihtiyacına cevap veren database değildir. Event log lookup için optimize olmayabilir. Transactional query semantics sınırlıdır. Consumer kendi read model'ini oluşturabilir. Storage rolü doğru sınırlandırılmalıdır.

Sık Yapılan Transactional Outbox Hataları

Transactional Outbox doğru uygulanmadığında dual-write problemi farklı biçimde devam edebilir. Outbox insert business transaction dışında yapılırsa atomicity kaybolur. Table cleanup yapılmazsa storage büyür. Relay'in duplicate publish yapamayacağını varsaymak consumer idempotency'nin ihmal edilmesine yol açar. Ordering gereksinimi de outbox row sırasından ayrı olarak açık biçimde tanımlanmalıdır.

Outbox Insert'ünü Business Transaction Dışında Yapmak

Business commit ve outbox insert ayrı olursa crash arası oluşur. Event kaybolabilir. Dual-write problemi çözülmez. Aynı transaction kullanılmalıdır. Unit of Work buna göre tasarlanmalıdır.

Outbox Table'ı Temizlememek

Processed outbox kayıtları zamanla büyür. Query performansı düşebilir. Storage maliyeti artar. Retention policy gerekir. Partitioning veya archive kullanılabilir.

Relay Duplicate Yayınlayamaz Sanmak

Relay publish sonrası crash olabilir. Processed flag yazılmadan event yeniden publish edilir. Duplicate normaldir. Event ID korunmalıdır. Consumer idempotent olmalıdır.

Consumer Idempotency'yi İhmal Etmek

Outbox producer güvenilirliğini artırır. Consumer side effect'i otomatik korumaz. Duplicate publish mümkündür. ProcessedMessages veya doğal idempotency gerekir. İki desen birlikte düşünülmelidir.

Ordering Gereksinimini Tanımlamamak

Outbox kayıt sırası business event sırası olmak zorunda değildir. Paralel transaction commit sırası değişebilir. Aggregate version taşınmalıdır. Relay partition key doğru kullanmalıdır. Ordering scope açık olmalıdır.

Sık Yapılan Consumer Hataları

Consumer tarafındaki en kritik hatalar acknowledgement zamanlaması ve retry davranışından kaynaklanır. Side effect'ten önce ack veya offset commit message loss riski doğurur. Poison message için sonsuz retry bütün consumer kapasitesini tüketebilir. Duplicate event'i hata saymak at-least-once modelini yanlış yorumlamaktır. Graceful shutdown ve slow consumer monitoring bulunmadığında deployment ve kapasite sorunları production'da daha sık görülür.

Side Effect'ten Önce Ack/Offset Commit

Ack önce yapılırsa broker mesajı tamamlanmış sanır. Consumer sonra crash olabilir. Business operation gerçekleşmez. Mesaj tekrar gelmez. Data loss oluşabilir.

Poison Message İçin Sonsuz Retry

Invalid event sürekli hata verir. Consumer aynı mesajda takılır. Queue lag büyür. Maximum retry gerekir. DLQ terminal yol sağlar.

İşlem Tamamlanmadan Commit

Processing async çalışırken offset erken commit edilebilir. Worker failure mesajı kaybettirebilir. Completion sinyali beklenmelidir. Batch mode ayrıca test edilmelidir. Commit strategy açık olmalıdır.

Duplicate Event'i Hata Saymak

Duplicate at-least-once modelinde normaldir. Error log gürültüsü oluşturulmamalıdır. Metric ayrı tutulabilir. Business operation skip edilmelidir. Ack başarılı yapılabilir.

Slow Consumer'ı İzlememek

Consumer çalışıyor görünse bile yetişemeyebilir. Lag sürekli büyür. Kullanıcı sonuçları gecikir. Health check bunu yakalamayabilir. Throughput ve time lag izlenmelidir.

Graceful Shutdown Yapmamak

Deployment process'i aniden kapatabilir. In-flight message yarıda kalır. Duplicate redelivery olur. External side effect belirsiz kalabilir. Shutdown hook uygulanmalıdır.

Sık Yapılan Event Schema Hataları

Event schema hataları genellikle contract'ın internal DTO gibi görülmesinden kaynaklanır. Field type'ını doğrudan değiştirmek eski consumer'ları bozabilir. Yeni required field eklemek geçmiş event replay'ini zorlaştırır. Consumer kullanımı bilinmeden field silmek production incident oluşturabilir. Schema Registry ve compatibility policy kullanılmadığında bu riskler code review sırasında kolayca gözden kaçabilir.

Field Type'ını Doğrudan Değiştirmek

String field integer yapılırsa eski consumer deserialize edemeyebilir. Yeni field oluşturmak daha güvenlidir. Migration süreci uygulanabilir. Eski field deprecated edilir. Compatibility gate değişikliği durdurabilir.

Required Field Eklemek

Yeni required field eski event'lerde bulunmaz. Replay failure oluşabilir. Eski producer'lar yeni field'i göndermez. Optional eklemek daha güvenlidir. Default business anlamıyla tanımlanmalıdır.

Consumer'ları Bilmeden Field Silmek

Field artık producer'da kullanılmıyor olabilir. Consumer hâlâ bağımlı olabilir. Catalog usage kontrol edilmelidir. Deprecation dönemi tanımlanmalıdır. Kaldırma sonrası monitoring yapılmalıdır.

Schema Registry Kullanmamak

Schema kontrolü yoksa contract drift oluşur. Producer farklı type gönderebilir. Consumer runtime'da hata alır. CI compatibility mümkün olmaz. Küçük sistemlerde bile en azından versioned schema faydalıdır.

Event'i Uygulamanın Internal DTO'su Gibi Tasarlamak

Internal DTO sık değişebilir. Event dış consumer'lara uzun süre hizmet eder. Aynı class'ı paylaşmak coupling oluşturur. Ayrı integration model kullanılmalıdır. Mapping bilinçli contract boundary yaratır.

Örnek Production-Ready Event-Driven Akış

Production-ready bir event-driven akış HTTP command ile başlayıp business transaction, Outbox, broker, idempotent consumer ve observability adımlarını birlikte içerir. Amaç tek bir teknoloji göstermek değil, failure noktalarını kontrol altına almaktır. Event broker'a güvenilir biçimde ulaşmalı ve consumer duplicate teslimi güvenli karşılamalıdır. Retry ve DLQ kalıcı hataları ana akıştan ayırmalıdır. Metrics, logs ve traces tüm yaşam döngüsünü gözlemlenebilir hâle getirmelidir.

1. HTTP Command Alınır

Kullanıcı veya başka servis HTTP command gönderir. Authentication yapılır. Input validation uygulanır. Correlation ID oluşturulur veya alınır. Business operation başlatılır.

2. Business Transaction Başlar

Database transaction açılır. Aggregate veya business row yüklenir. Constraint kontrol edilir. Concurrency strategy uygulanır. Event henüz broker'a publish edilmez.

3. Business State Güncellenir

İş kuralı başarılıysa state değiştirilir. Version artırılabilir. Database change transaction içinde kalır. Domain event oluşabilir. Hata varsa rollback yapılır.

4. Event Outbox'a Yazılır

Integration event outbox row olarak eklenir. Event ID üretilir. Metadata kaydedilir. Payload serialize edilir. Aynı database transaction kullanılır.

5. Transaction Commit Edilir

Business row ve outbox row birlikte commit olur. İkisi de kalıcı hâle gelir. Crash sonrası outbox event kaybolmaz. Kullanıcıya uygun response döndürülebilir. Broker publish daha sonra yapılabilir.

6. CDC/Relay Event'i Broker'a Yayar

Relay outbox kaydını bulur. Kafka veya başka broker'a publish eder. Confirmation alınır. Duplicate publish ihtimali kabul edilir. Outbox processing state güncellenir.

7. Consumer Event'i Alır

Consumer topic veya queue'dan event'i alır. Schema doğrulaması yapar. Trace context çıkarılır. Event ID okunur. Business handler çağrılır.

8. Event ID ile Deduplication Yapılır

ProcessedMessages kaydı kontrol edilir. Unique constraint duplicate'i engeller. Daha önce işlendiysa business operation atlanır. Mesaj başarılı kabul edilir. Duplicate metric artırılabilir.

9. Business İşlemi Gerçekleştirilir

Consumer local transaction başlatır. Kendi business state'ini günceller. Gerekirse yeni outbox event üretir. External side effect idempotency key kullanır. Transaction commit edilir.

10. Offset/Ack Kaydedilir

Business operation tamamlandıktan sonra ack veya offset commit yapılır. Crash öncesi failure duplicate delivery oluşturabilir. Consumer buna hazırdır. Commit latency metric olarak izlenebilir. Erken commit yapılmaz.

11. Başarısızlıkta Retry/DLQ Çalışır

Retryable error backoff ile tekrar denenir. Jitter retry dalgasını dağıtır. Maximum attempts uygulanır. Kalıcı hata DLQ'ya gider. Alert ve investigation süreci başlar.

12. Metrics, Log ve Trace Kaydedilir

Processing rate metric güncellenir. Structured log event ID içerir. Trace span processing latency'yi gösterir. Error classification kaydedilir. Dashboard SLO durumunu görünür kılar.

Production İçin Event Envelope Örneğinde Hangi Alanlar Olmalı?

Production event envelope hem business payload'ı hem de operasyon metadata'sını taşır. id, type, source ve time event'in temel kimliğini verir. schemaVersion contract evolution için kullanılır. correlationId, causationId ve traceparent distributed debugging'i güçlendirir. Multi-tenant ihtiyaçlarda tenantId eklenebilir ve asıl business veri data alanında tutulabilir.

id

id event'in benzersiz kimliğidir. Duplicate detection için kullanılır. Replay sırasında korunur. Log ve trace eşleştirmesi sağlar. Global uniqueness tercih edilir.

type

type event'in business anlamını belirtir. OrderCreated gibi isim kullanılabilir. Consumer routing için değerlidir. Version convention açık olmalıdır. Teknik class adına bağlı olmamalıdır.

source

source event'i hangi domain veya servis ürettiğini gösterir. Owner discovery sağlar. CloudEvents standardıyla uyumlu tutulabilir. Physical instance bilgisi taşımamalıdır. Kararlı identifier kullanılmalıdır.

subject

subject event'in ilgili olduğu business resource'u gösterebilir. Order ID buna örnektir. Filtering kolaylaşır. Hassas identifier riski değerlendirilmelidir. Partition key ile aynı olmak zorunda değildir.

time

time event oluşum anıdır. UTC timestamp kullanılabilir. Processing time'dan ayrıdır. Event latency hesaplamasına yardım eder. Ordering için tek başına yeterli değildir.

schemaVersion

schemaVersion data contract sürümünü belirtir. Consumer uygun parser seçebilir. Registry version ile eşleştirilebilir. Breaking migration takibini kolaylaştırır. Semantic rule dokümante edilmelidir.

correlationId

correlationId aynı business flow'u bağlar. HTTP request'ten event'e taşınabilir. Saga boyunca korunur. Log aramasını kolaylaştırır. Yeni bağımsız flow için yenilenebilir.

causationId

causationId event'i doğrudan tetikleyen message ID'sidir. Nedensel zincir kurar. Debugging sırasında parent event bulunur. Saga flow açıklığı artar. Event loop analizi kolaylaşır.

traceparent

traceparent W3C trace context bilgisini taşır. Producer ve consumer span'ları bağlanır. OpenTelemetry ile otomatik propagate edilebilir. Güvenilmeyen source'tan gelen header doğrulanmalıdır. Sampling davranışı uyumlu olmalıdır.

tenantId

tenantId multi-tenant sistemde data ownership'i gösterir. Authorization kontrolünde kullanılabilir. Partition key olarak seçildiğinde distribution etkilenir. Loglarda masking gerekebilir. Tenant olmayan sistemlerde eklenmesi gereksizdir.

data

data asıl business payload'ıdır. Schema ile tanımlanmalıdır. Yalnızca consumer'ın ihtiyacı olan alanları taşımalıdır. Hassas veri minimize edilmelidir. Envelope metadata'dan ayrı tutulmalıdır.

Event-Driven Architecture Monitoring Dashboard'ında Neler Olmalı?

Monitoring dashboard producer, broker ve consumer davranışını aynı ekranda ilişkilendirebilmelidir. Publish ve consume rate trafik akışını gösterir. Error, retry ve DLQ metrikleri failure davranışını görünür kılar. Consumer lag, queue depth ve end-to-end latency business gecikmesini açıklar. Broker disk ve partition distribution kapasite ve hot spot sorunlarını erken tespit etmeye yardımcı olur.

Publish Rate

Publish Rate event giriş hızını gösterir. Traffic trendi kolay görülür. Ani düşüş producer failure olabilir. Ani artış capacity riskidir. Historical baseline eklenebilir.

Consume Rate

Consume Rate işlenen event hızını gösterir. Publish rate ile karşılaştırılmalıdır. Düşük kalırsa backlog büyür. Instance bazlı görünüm faydalıdır. Autoscaling etkisi izlenebilir.

Error Rate

Error Rate processing veya publish failure oranıdır. Error class segmentasyonu yapılmalıdır. Deployment annotation eklenebilir. Ani artış hızlı fark edilir. SLO burn rate hesaplanabilir.

Consumer Lag

Consumer Lag bekleyen event miktarını gösterir. Partition bazında gösterilmelidir. Time lag eklenmelidir. Trend grafiği capacity sorununu erken gösterir. Alarm business threshold'a bağlanmalıdır.

Queue Depth

Queue Depth bekleyen message sayısıdır. RabbitMQ gibi sistemlerde temel metriktir. Growth rate önemlidir. Ready ve unacked message ayrı izlenebilir. Disk alarmıyla ilişkilendirilebilir.

DLQ Size

DLQ Size terminal failure backlog'unu gösterir. Sadece toplam sayı değil yaş dağılımı da önemlidir. En eski mesaj yaşı remediation SLA'yı gösterir. Event type bazında kırılım yapılabilir. Owner görünür olmalıdır.

Retry Rate

Retry Rate geçici failure yoğunluğunu gösterir. Normal traffic oranıyla karşılaştırılabilir. Retry storm erken tespit edilir. Downstream incident ile korelasyon yapılır. Threshold dinamik olabilir.

End-to-End Latency

End-to-End Latency event üretiminden completion'a kadar süreyi gösterir. p50, p95 ve p99 sunulmalıdır. Queue wait ayrı gösterilebilir. Processing latency ayrı görünmelidir. Business SLO doğrudan bağlanabilir.

Broker Disk

Broker Disk retention ve backlog etkisini gösterir. Kullanım yüzdesi alarm için önemlidir. Growth rate capacity tahmini sağlar. Partition distribution dengesizliği görülebilir. Kritik threshold öncesinde aksiyon alınmalıdır.

Partition Distribution

Partition Distribution broker ve consumer yükünün dengeli olup olmadığını gösterir. Hot partition tespit edilir. Message key problemi anlaşılır. Leader distribution izlenebilir. Reassignment sonrası karşılaştırma yapılabilir.

Event-Driven Architecture SLI/SLO Örnekleri

Event-driven SLI ve SLO'lar sistem güvenilirliğini ölçülebilir hedeflere dönüştürür. Event Delivery Success Rate producer tarafındaki güvenilirliği gösterir. Event Processing Success Rate consumer sonucunu ölçer. p95 end-to-end latency ve maximum consumer lag kullanıcı veya business gecikmesini sınırlar. DLQ rate ve schema compatibility success rate kalite ve contract sağlığını takip etmek için ek hedefler sunar.

Event Delivery Success Rate

Bu SLI broker'a başarıyla ulaşan event oranını ölçer. Outbox pending kayıtları dahil edilebilir. Publish retry sonucu dikkate alınmalıdır. Kritik event'lerde yüksek hedef belirlenir. Error budget incident yönetiminde kullanılır.

Event Processing Success Rate

Consumer'ın başarıyla tamamladığı event oranını gösterir. Retry sonrası başarı policy'ye göre sayılabilir. Business validation ayrı tutulmalıdır. DLQ terminal failure olarak değerlendirilebilir. Event type bazında hedef değişebilir.

p95 End-to-End Latency

Event'lerin yüzde 95'inin tamamlanma süresini ölçer. Queue wait ve processing dahildir. Business kullanıcı açısından anlamlıdır. Peak traffic'te izlenmelidir. SLO breach alert üretir.

Maximum Consumer Lag

Maximum Lag kabul edilen en yüksek backlog sınırını belirler. Mesaj sayısı veya süre olarak tanımlanabilir. Time lag çoğu business için daha anlaşılırdır. Kısa peak tolerance eklenebilir. Sürekli breach capacity problemi gösterir.

DLQ Rate

DLQ Rate işlenemeyen event oranını gösterir. Kritik event'lerde çok düşük hedef konur. Invalid external data ayrı kategori olabilir. Trend producer kalite problemini açığa çıkarır. Remediation SLA ile birlikte kullanılmalıdır.

Schema Compatibility Success Rate

Schema pipeline değişikliklerinin compatibility testinden geçme oranı izlenebilir. Failure quality gate'in çalıştığını gösterir. Bypass sayısı ayrıca önemlidir. Çok yüksek failure eğitim ihtiyacına işaret edebilir. Governance maturity ölçümünde kullanılabilir.

Event-Driven Architecture Maturity Model

Event-driven maturity yalnızca broker kurulumu ile ölçülmez. İlk seviyelerde sistem senkron entegrasyondan temel queue ve pub/sub modeline geçer. Retry, DLQ ve monitoring operasyon güvenilirliğini artırır. Idempotency, Outbox, Schema Registry, Saga ve distributed tracing ilerleyen seviyelerde devreye girer. En olgun seviyelerde kurum çapında event platformu, automated policy, SLO ve event product yaklaşımı birlikte çalışır.

Seviye 0 — Senkron Point-to-Point Entegrasyon

Servisler doğrudan HTTP ile birbirini çağırır. Dependency chain açıkça görülür. Basit sistemlerde yeterlidir. Failure cascade riski büyüyebilir. Event platform henüz yoktur.

Seviye 1 — Temel Queue / Pub-Sub

İlk asenkron mesaj akışları kurulur. Queue veya topic kullanılır. Producer consumer'dan ayrılır. Delivery policy temel seviyededir. Governance henüz sınırlıdır.

Seviye 2 — Retry + DLQ + Monitoring

Failure davranışı operasyonel hâle gelir. Retry sınırlı ve kontrollüdür. DLQ terminal hata toplar. Dashboard lag ve error gösterir. Owner sorumluluğu netleşmeye başlar.

Seviye 3 — Idempotency + Outbox + Schema Registry

Producer ve consumer reliability güçlenir. Dual-write Outbox ile çözülür. Duplicate delivery idempotency ile karşılanır. Schema compatibility otomatik kontrol edilir. Contract lifecycle daha güvenlidir.

Seviye 4 — Saga + Distributed Tracing + Governance

Cross-service workflow Saga ile yönetilir. Correlation ve causation ID standarttır. Distributed tracing production'da aktiftir. Event catalog ownership gösterir. Deprecation policy uygulanır.

Seviye 5 — Replay-Safe + SLO + Automated Policy

Consumer'lar replay-safe tasarlanır. SLO ve error budget izlenir. Schema ve security policy otomatik uygulanır. DR replay planı test edilir. Platform self-service özellikleri gelişir.

Seviye 6 — Kurum Çapında Event Platformu ve Event Product Yaklaşımı

Event'ler kurum içi ürün gibi yönetilir. Discoverability güçlüdür. Owner, SLO ve contract lifecycle standarttır. Self-service tooling ekipleri hızlandırır. Platform governance ölçeklenebilir hâle gelir.

Production'a Çıkmadan Önce Event-Driven Sistem Kontrol Listesi

Production öncesi kontrol yalnızca broker'ın çalıştığını görmekten ibaret değildir. Event ve command semantiği, ownership, schema, delivery semantics ve idempotency doğrulanmalıdır. Dual-write, retry, DLQ ve ordering davranışları failure testleriyle sınanmalıdır. Lag monitoring, distributed tracing, broker HA ve capacity testleri operasyon hazırlığını gösterir. Disaster recovery ve replay planı gerçek bir tatbikatla doğrulanmadan event-driven sistemin güvenilir olduğu varsayılmamalıdır.

Event ve Command Ayrımı Net mi?

Event gerçekleşmiş bir fact olmalıdır. Command yapılması istenen işi anlatmalıdır. İsimler bu ayrımı yansıtmalıdır. Retry semantics dokümante edilmelidir. Review sırasında kontrol edilmelidir.

Event Owner Belli mi?

Her event'in owner ekibi olmalıdır. Catalog içinde görünmelidir. Schema change review owner'a gitmelidir. Incident alert doğru ekibe ulaşmalıdır. Sahipsiz event production'a çıkmamalıdır.

Event ID Var mı?

Her event benzersiz ID taşımalıdır. Duplicate detection bunu kullanır. Replay sırasında korunmalıdır. Log ve trace aramasında kullanılmalıdır. Format standart olmalıdır.

Correlation ID Var mı?

Business flow correlation ID taşımalıdır. HTTP'den event'e propagate edilmelidir. Consumer yeni değer üretmemelidir. Saga debugging kolaylaşır. Log standardına eklenmelidir.

Schema Tanımlı mı?

Event payload resmi schema'ya sahip olmalıdır. Field type ve optional kuralları açık olmalıdır. Metadata standardı tanımlanmalıdır. Schema versionlanmalıdır. Documentation mevcut olmalıdır.

Schema Compatibility Kontrol Ediliyor mu?

CI yeni schema'yı eski version ile karşılaştırmalıdır. Breaking change gate olmalıdır. Registry policy uygulanmalıdır. Override sınırlı olmalıdır. Migration planı istenmelidir.

Delivery Semantics Biliniyor mu?

At-most-once veya at-least-once davranışı açık olmalıdır. Broker ve client configuration bunu desteklemelidir. Business guarantee ayrıca yazılmalıdır. Team duplicate riskini anlamalıdır. Testler gerçek semantics'i doğrulamalıdır.

Consumer Idempotent mı?

Aynı event iki kez test edilmelidir. Business side effect değişmemelidir. Event ID kontrolü bulunmalıdır. Unique constraint uygulanabilir. External API idempotency düşünülmelidir.

Dual-Write Problemi Çözüldü mü?

Database ve broker publish ayrı bırakılmamalıdır. Outbox veya eşdeğer güvenilir çözüm kullanılmalıdır. Failure window test edilmelidir. Relay duplicate publish ihtimali anlaşılmalıdır. Reconciliation planı bulunmalıdır.

Retry Politikası Var mı?

Retryable ve non-retryable error ayrılmalıdır. Backoff ve jitter kullanılmalıdır. Maximum attempts belirlenmelidir. Retry storm sınırlandırılmalıdır. Policy dokümante edilmelidir.

DLQ Var mı?

Terminal failure için DLQ bulunmalıdır. Original payload ve metadata korunmalıdır. Retention tanımlanmalıdır. Access control uygulanmalıdır. Alert aktif olmalıdır.

DLQ İşletim Süreci Var mı?

DLQ owner belli olmalıdır. Remediation SLA tanımlanmalıdır. Replay tooling bulunmalıdır. Audit trail tutulmalıdır. Düzenli review yapılmalıdır.

Ordering Scope Tanımlandı mı?

Global ordering varsayılmamalıdır. Aggregate veya partition scope yazılmalıdır. Message key seçimi doğrulanmalıdır. Out-of-order behavior test edilmelidir. Version metadata kullanılmalıdır.

Consumer Lag İzleniyor mu?

Lag dashboard'da görünmelidir. Time lag metriği eklenmelidir. Growth rate alarmı olabilir. Partition bazında incelenmelidir. Business SLO ile ilişkilendirilmelidir.

Replay Test Edildi mi?

Gerçek event aralığı staging'de replay edilmelidir. Duplicate side effect olmamalıdır. Projection doğru oluşmalıdır. Rate limit test edilmelidir. Recovery runbook güncellenmelidir.

Distributed Trace Var mı?

Trace context event üzerinden taşınmalıdır. Producer ve consumer span oluşmalıdır. Correlation ID ile eşleşmelidir. Sampling policy belirlenmelidir. Trace dashboard incident kullanımına uygun olmalıdır.

Broker HA Planlandı mı?

Replication doğru yapılandırılmalıdır. Zone failure senaryosu test edilmelidir. Client failover çalışmalıdır. Quorum gereksinimi bilinmelidir. Capacity yedek payı bırakılmalıdır.

Capacity Testi Yapıldı mı?

Peak EPS load test edilmelidir. Consumer throughput ölçülmelidir. Lag growth gözlemlenmelidir. Broker disk etkisi hesaplanmalıdır. Message size dağılımı gerçekçi olmalıdır.

Disaster Recovery Planı Var mı?

RPO ve RTO tanımlanmalıdır. Broker backup ve replication test edilmelidir. Offset recovery planı bulunmalıdır. Schema Registry restore edilmelidir. DR drill düzenli yapılmalıdır.

Sık Sorulan Sorular

Event-driven mimari hakkında en çok sorulan sorular genellikle iletişim modeli, broker seçimi, delivery semantics ve veri tutarlılığı etrafında toplanır. Bu soruların tek bir teknolojiye dayanan kısa cevapları çoğu zaman eksik kalır. Aşağıdaki bölümlerde mimari kararların business gereksinimiyle nasıl ilişkilendirileceği özetlenmektedir. Kafka veya RabbitMQ seçimi kadar idempotency, Outbox ve observability tasarımı da önemlidir. Özellikle production hedefleniyorsa failure senaryolarının ilk tasarımın parçası olması gerekir.

Event-driven architecture nedir?

Event-driven architecture bileşenlerin gerçekleşen olayları yayınlayıp diğer bileşenlerin bu olaylara tepki verdiği iletişim modelidir. Producer ve consumer birbirini doğrudan bilmek zorunda değildir. Broker mesajların taşınmasını sağlar. Sistem asenkron çalışabilir. Güvenilirlik için schema, retry, idempotency ve observability birlikte tasarlanmalıdır.

Backend sistemlerinde event-driven iletişim nasıl çalışır?

Backend servisi business event üretir ve broker'a yayınlar. Event topic veya queue üzerinde taşınır. Consumer mesajı alıp kendi local işlemini yürütür. Ack veya offset processing tamamlandıktan sonra kaydedilir. Failure durumunda retry ve DLQ devreye girer.

Event ile message arasındaki fark nedir?

Event gerçekleşmiş business fact'i temsil eder. Message daha genel transport kavramıdır. Bir message event veya command taşıyabilir. Broker business semantiğini bilmeyebilir. Uygulama contract'ı message'ın gerçek anlamını belirler.

Event ile command arasındaki fark nedir?

Event geçmişte gerçekleşmiş olayı anlatır. Command yapılması istenen işi temsil eder. OrderCreated event'tir. CreateOrder command'dir. İsimlendirme retry ve ownership davranışını anlamayı kolaylaştırır.

Kafka mı RabbitMQ mu kullanılmalı?

Replay ve distributed log ihtiyacı güçlü ise Kafka avantajlı olabilir. Esnek queue routing ve worker modeli gerekiyorsa RabbitMQ daha doğal olabilir. Throughput tek karar ölçütü değildir. Operasyon deneyimi ve retention ihtiyacı değerlendirilmelidir. Workload test sonucu seçimde belirleyici olmalıdır.

Message queue ile pub/sub arasındaki fark nedir?

Queue genellikle bir mesajı consumer'lardan birine dağıtır. Pub/sub aynı event'i birden fazla bağımsız subscriber'a iletir. Work queue görev dağıtımı için uygundur. Topic event yayılımı için daha doğaldır. Consumer ownership modeli buna göre değişir.

At-least-once delivery nedir?

At-least-once message'ın başarı sağlanana kadar yeniden teslim edilebilmesini kabul eder. Duplicate mesaj oluşabilir. Consumer idempotent olmalıdır. Ack processing sonrasında yapılır. Bu model veri kaybı riskini azaltır.

Exactly-once delivery gerçekten mümkün mü?

Belirli broker sınırlarında exactly-once benzeri garanti mümkündür. External database ve API dahil olduğunda problem daha geniştir. Commit ile ack arasında failure window bulunabilir. Business side effect idempotent olmalıdır. Scope belirtilmeden exactly-once iddiası eksik kalır.

Idempotent consumer nedir?

Idempotent consumer aynı event tekrar geldiğinde business sonucunu değiştirmez. Event ID duplicate detection için kullanılır. Processed table tutulabilir. Unique constraint yarış koşullarını önler. Side effect yalnızca bir kez uygulanır.

Transactional Outbox nedir?

Transactional Outbox business update ile event kaydını aynı database transaction içinde tutar. Outbox row commit sonrası relay tarafından broker'a yayınlanır. Böylece dual-write failure window azaltılır. Relay duplicate publish yapabilir. Consumer yine idempotent olmalıdır.

Dual-write problemi nedir?

Dual-write iki bağımsız sisteme aynı operation içinde yazma problemidir. Database başarılı olup broker publish başarısız olabilir. Tersi durumda event yayınlanıp database rollback olabilir. Atomicity kaybolur. Outbox bu problemi yönetmek için kullanılır.

Inbox pattern nedir?

Inbox gelen event'i consumer database'inde kalıcı olarak saklar. Event ID duplicate detection sağlar. Processing state retry'ı yönetir. Crash sonrası iş devam edebilir. Cleanup ve retention politikası gerekir.

Dead Letter Queue nedir?

DLQ maksimum retry sonrası işlenemeyen mesajları saklar. Poison message ana queue'yu tıkamaz. Error metadata investigation sağlar. Owner ve remediation SLA tanımlanmalıdır. Replay tooling operasyon sürecinin parçasıdır.

DLQ'ya düşen mesajlar nasıl tekrar işlenir?

Önce root cause araştırılır. Gerekirse payload düzeltilir. Mesaj kontrollü replay mekanizmasıyla normal akışa alınır. Event ID korunur. Replay rate downstream kapasiteyi aşmamalıdır.

Event ordering nasıl sağlanır?

Ordering scope önce tanımlanmalıdır. Kafka'da aynı aggregate key aynı partition'a gönderilebilir. Sequence number veya aggregate version taşınabilir. Out-of-order event consumer tarafından tespit edilir. Global ordering mümkün olduğunca kaçınılmalıdır.

Kafka partition key nasıl seçilir?

Partition key business ordering requirement'ı yansıtmalıdır. Order ID veya Account ID iyi örnek olabilir. High-cardinality dağılımı iyileştirir. Tek tenant key hot partition oluşturabilir. Production trafik dağılımıyla test yapılmalıdır.

Consumer lag nedir?

Consumer lag producer'ın ulaştığı konum ile consumer'ın işlediği konum arasındaki farktır. Kafka'da offset üzerinden ölçülür. Queue sistemlerinde queue depth benzer sinyal verir. Sürekli artış consumer kapasite problemini gösterebilir. Time lag business açısından daha açıklayıcı olabilir.

Schema Registry nedir?

Schema Registry event contract'larını merkezi olarak saklar. Version ve compatibility yönetir. Producer validation yapılabilir. Consumer contract güvenilir hâle gelir. CI pipeline breaking change'i engelleyebilir.

Event schema nasıl versionlanır?

Öncelikle backward compatible evolution tercih edilmelidir. Breaking change gerekiyorsa event type veya topic version kullanılabilir. V1 ve V2 geçici birlikte çalışabilir. Consumer migration izlenmelidir. Eski version kontrollü deprecate edilmelidir.

Saga pattern nedir?

Saga dağıtık business transaction'ı local transaction adımlarına böler. Her servis kendi state'ini commit eder. Failure durumunda compensation çalışır. Eventual consistency kabul edilir. Choreography veya orchestration modeli kullanılabilir.

Saga choreography ile orchestration arasındaki fark nedir?

Choreography merkezi coordinator olmadan event tepkileriyle ilerler. Orchestration merkezi Saga orchestrator kullanır. Choreography loose coupling sağlar. Orchestration workflow visibility artırır. Seçim flow uzunluğu ve debugging ihtiyacına bağlıdır.

Event Sourcing ile Event-Driven Architecture aynı şey midir?

Hayır, aynı şey değildir. EDA bir iletişim modelidir. Event Sourcing persistence modelidir. Birlikte kullanılabilirler. Her event-driven sistem Event Sourcing kullanmak zorunda değildir.

Event replay nasıl yapılır?

Consumer offset geçmiş konuma alınabilir. Event Store veya broker history yeniden okunabilir. Consumer replay-safe olmalıdır. External side effect suppress edilebilir. Rate limit ve audit uygulanmalıdır.

Event-driven sistemler nasıl test edilir?

Unit, contract, integration ve end-to-end testler birlikte kullanılmalıdır. Gerçek broker için Testcontainers faydalıdır. Duplicate ve out-of-order event test edilmelidir. Consumer crash ve broker unavailable senaryosu çalıştırılmalıdır. Replay testleri production öncesinde tamamlanmalıdır.

Event-driven sistemlerde distributed tracing nasıl yapılır?

Trace context event metadata içine taşınır. W3C traceparent kullanılabilir. Producer span publish işlemini temsil eder. Consumer span processing süresini gösterir. OpenTelemetry servisler arasında ortak tracing sağlar.

Sonuç: Güvenilir Event-Driven Backend Mimarisi Nasıl Tasarlanır?

Backend Sistemlerinde Event-Driven (Olay Güdümlü) İletişim doğru uygulandığında servis bağımsızlığı, ölçeklenebilirlik ve failure isolation açısından güçlü bir temel sağlar. Ancak broker kurmak tek başına production-ready mimari oluşturmaz. Event semantics, Outbox, idempotency, retry, DLQ, schema governance, observability ve replay tasarımı birlikte ele alınmalıdır. İlişkisel ve ilişkisel olmayan veri modellerinin birlikte kullanımı konusunda ek teknik yaklaşım için https://www.diyarbakiryazilim.com.tr/posts/iliskisel-ve-iliskisel-olmayan-veritabanlarinin-birlikte-kullanimi adresindeki içeriği inceleyebilirsiniz. Uygulama örnekleri ve geliştirilen çalışmalar için https://www.diyarbakiryazilim.com.tr/projects, topluluk hakkında bilgi için ise https://www.diyarbakiryazilim.com.tr/about adresini ziyaret edebilirsiniz.

Teknolojiden Önce Event Semantiğini Tasarlayın

İlk soru hangi broker'ı kullanacağınız olmamalıdır. Önce hangi business event'lerin gerçekten var olduğunu belirleyin. Event ile command ayrımını netleştirin. Ownership ve contract lifecycle tanımlayın. Teknoloji bu semantiği taşıyan araç olarak seçilmelidir.

Duplicate Delivery'yi İstisna Değil Normal Durum Kabul Edin

Network failure ve retry duplicate event üretebilir. Bu davranış production'da kaçınılmaz olabilir. Consumer idempotent olmalıdır. Duplicate metric ayrı izlenebilir. Business side effect korunmalıdır.

Producer Tarafında Dual-Write Problemini Çözün

Database commit ile broker publish ayrı bırakılmamalıdır. Transactional Outbox güçlü bir çözüm sunar. Relay duplicate publish yapabilir. Reconciliation planı bulunmalıdır. Producer reliability failure test ile doğrulanmalıdır.

Consumer'ları Idempotent Tasarlayın

Event ID standardı kullanın. ProcessedMessages table uygulanabilir. Unique constraint yarış koşulunu önler. Business transaction ile deduplication birlikte yapılmalıdır. External API side effect için idempotency key kullanılmalıdır.

Event Schema'larını Uzun Ömürlü API Contract'ları Gibi Yönetin

Event contract birçok consumer tarafından yıllarca kullanılabilir. Internal DTO gibi sık değişmemelidir. Schema Registry ve compatibility gate kullanın. Deprecation policy tanımlayın. Consumer catalog ile impact analysis yapın.

Ordering Gereksinimini En Dar Scope'ta Tutun

Global ordering çoğu sistem için gereksizdir. Aggregate-level ordering daha iyi ölçeklenir. Message key business scope'u yansıtmalıdır. Sequence veya version metadata eklenebilir. Hot partition davranışı izlenmelidir.

Retry, Backoff ve DLQ'yu Birlikte Tasarlayın

Retry tek başına resilience değildir. Retryable hata sınıflandırılmalıdır. Exponential backoff ve jitter uygulanmalıdır. Maximum attempts sonrası DLQ devreye girmelidir. DLQ için owner ve remediation süreci bulunmalıdır.

Replay ve Recovery'yi Production Öncesinde Test Edin

Replay ilk kez incident sırasında denenmemelidir. Staging ortamında gerçek event akışıyla test edilmelidir. Side effect suppression doğrulanmalıdır. Throughput limiti belirlenmelidir. Recovery runbook ölçülen sonuçlarla güncellenmelidir.

Correlation ID ve Distributed Tracing'i İlk Günden Ekleyin

Asenkron flow büyüdükten sonra tracing eklemek daha zordur. Correlation ID ilk request'ten itibaren taşınmalıdır. Causation ID event zincirini göstermelidir. OpenTelemetry trace context propagate edebilir. Incident çözüm süresi ciddi biçimde kısalır.

Event-Driven Architecture'ı “Kafka Kullanmak” Değil Dağıtık Sistemlerde Güvenilir İletişim ve Veri Tutarlılığı Disiplini Olarak Ele Alın

Backend Sistemlerinde Event-Driven (Olay Güdümlü) İletişim bir broker ürünü seçmekten çok daha geniş bir mühendislik disiplinidir. Production başarısı event contract, failure handling, consistency ve operability kararlarının kalitesine bağlıdır. Event-driven mimari ve backend danışmanlığı yakınımda şeklinde bir arama yapıyorsanız, Diyarbakır Yazılım Topluluğu üzerinden teknik içeriklere, projelere ve topluluk çalışmalarına ulaşabilirsiniz. Kurumsal event-driven backend ve mikroservis mimarisi geliştirme hizmeti veya teknik eğitim ihtiyaçlarınızı değerlendirmek için https://www.diyarbakiryazilim.com.tr adresini kullanabilirsiniz. Güvenilir bir sistem kurmak istiyorsanız teknoloji seçimine başlamadan önce event akışlarını, hata senaryolarını ve veri tutarlılığı hedeflerini birlikte tasarlamak en sağlam başlangıç noktasıdır.

Backend sistemlerinde Event-Driven (olay güdümlü) iletişim nedir ve nasıl çalışır?

Backend Sistemlerinde Event-Driven (Olay Güdümlü) İletişim, bir serviste gerçekleşen önemli business olayının event olarak yayınlanması ve ilgili servislerin bu event'e bağımsız biçimde tepki vermesi yaklaşımıdır. Producer event'i broker'a gönderir, broker mesajı topic veya queue üzerinde tutar ve consumer uygun zamanda işler. Producer consumer sonucunu doğrudan beklemek zorunda olmadığı için servisler daha bağımsız çalışabilir. Production ortamında idempotency, retry, DLQ, schema ve observability gibi unsurlar bu akışın güvenilirliğini sağlar. Bu nedenle olay güdümlü iletişim yalnızca asenkron mesajlaşma değil, failure ve veri tutarlılığı davranışlarının da birlikte tasarlandığı bir backend disiplinidir.

Event-Driven mimari ile senkron REST API iletişimi arasındaki farklar nelerdir?

REST API iletişiminde çağıran servis çoğunlukla karşı servisin yanıtını bekler. Event-driven iletişimde producer mesajı yayınlayıp kendi akışına devam edebilir. Senkron model anında sonuç gereken işlemlerde sade bir kullanıcı deneyimi sunarken, event-driven model background processing ve servis bağımsızlığı için güçlüdür. REST zincirleri timeout ve cascading failure riski taşırken broker geçici servis kesintilerinde buffer görevi görebilir. Birçok production sisteminde en iyi sonuç HTTP command ile başlayan ve sonraki işleri async event üzerinden yürüten hibrit yaklaşımla elde edilir.

Kafka RabbitMQ ve benzeri message broker çözümleri olay güdümlü backend sistemlerinde nasıl kullanılır?

Kafka yüksek hacimli event stream, retention ve replay ihtiyaçlarında güçlü bir distributed log yaklaşımı sunar. RabbitMQ queue, acknowledgement ve esnek routing senaryolarında doğal bir kullanım modeli sağlar. Benzer managed veya açık kaynak broker'lar da farklı operasyon ve teslim özellikleri sunabilir. Seçim yapılırken throughput kadar ordering, retention, replay, routing ve ekip deneyimi değerlendirilmelidir. Broker seçildikten sonra producer reliability, consumer idempotency ve schema governance uygulama katmanında ayrıca tasarlanmalıdır.

Event-Driven sistemlerde event ordering idempotency retry ve veri tutarlılığı sorunları nasıl yönetilir?

Ordering mümkün olduğunca aggregate veya partition seviyesinde sınırlandırılmalıdır. Idempotency aynı event tekrar geldiğinde business side effect'in tekrarlanmamasını sağlar. Retry yalnızca geçici hatalara uygulanmalı ve exponential backoff ile jitter kullanılmalıdır. Producer tarafındaki dual-write problemi Transactional Outbox ile, consumer tarafındaki duplicate riski ise Inbox veya processed message yaklaşımıyla yönetilebilir. Eventual consistency kabul edilerek Saga, compensation ve reconciliation mekanizmaları kritik business flow'larda devreye alınabilir.

Event-Driven backend mimarisi ve mikroservis entegrasyonu konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Event-driven mimari eğitimi veya backend danışmanlığı ararken yalnızca Kafka ya da RabbitMQ kurulumuna odaklanan bir yaklaşım yerine distributed systems prensiplerini kapsayan teknik destek tercih etmek önemlidir. Event semantics, Outbox, idempotency, schema evolution, tracing, retry ve DLQ gibi konular gerçek production hazırlığının temelini oluşturur. Diyarbakır Yazılım Topluluğu'nun teknik çalışmaları ve topluluk yaklaşımı hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alabilirsiniz. Geliştirilen projeleri incelemek için https://www.diyarbakiryazilim.com.tr/projects adresini kullanabilirsiniz. Event-driven backend, mikroservis entegrasyonu ve ilgili teknik içeriklere ulaşmak için https://www.diyarbakiryazilim.com.tr adresi üzerinden topluluğa erişebilirsiniz.