Event-Driven Mimari ve Mesaj Kuyrukları Rehberi

Modern yazilim sistemleri, artan kullanici talepleri ve dagitik yapilar nedeniyle geleneksel senkron iletisim modellerinin sinirlarini zorlmaktadir. Event-driven mimari (olay tabanli mimari), bu zorluklarin ustesinden gelmek icin bilesenlerin olaylar araciligiyla iletisim kurdugu bir yaklasim sunar. Bu rehberde, event-driven mimarinin temellerini, mesaj kuyrugu teknolojilerini ve uretim ortaminda karsilasilan kritik tasarim kaliplarini ele aliyoruz.

Event-Driven Mimari Nedir ve Neden Kullanilir?

Event-driven mimari, sistem bilesenlerinin birbirleriyle dogrudan baglanti kurmak yerine olaylar (event) uzerinden iletisim sagladigi bir yazilim tasarim yaklasimidir. Bir bilesende meydana gelen degisiklik, bir olay olarak yayinlanir ve ilgili diger bilesenler bu olayi dinleyerek tepki verir.

Bu mimarinin temel avantajlari sunlardir:

• Gevsek baglilik (loose coupling): Uretici ve tuketici bilesenler birbirlerini dogrudan tanimak zorunda degildir. Yeni bir tuketici eklemek, ureticinin kodunda herhangi bir degisiklik gerektirmez.
• Olceklenebilirlik: Her bileseni bagimsiz olarak yatay olceklendirmek mumkundur. Yuk arttikca tuketici sayisi artirilabilir.
• Esneklik ve dayaniklilik: Bir bilesenin gecici olarak devre disi kalmasi tum sistemi durdurmaz. Mesajlar kuyrukta bekler ve bileseni yeniden ayaga kalktiginda islenmeye devam eder.
• Gercek zamanli isleme: Olaylar olusutuklari anda tuketicilere iletilir ve bu sayede dusuk gecikmeli veri isleme mumkun olur.

Senkron ve Asenkron Iletisim Karsilastirmasi

Senkron iletisimde, bir servis baska bir servisten istekte bulunur ve yanit gelene kadar bekler. REST API cagrilari bunun tipik bir ornekidir. Bu model basit senaryolar icin uygundur; ancak dagitik sistemlerde bagimliliklari artirarak kaskad hatalara yol acabilir.

Asenkron iletisimde ise mesaj gonderen taraf, alicinin mesaji ne zaman isleyecegini bilmez ve beklemez. Mesaj bir arakatman (broker) araciligiyla iletilir. Bu yaklasim su durumlarda tercih edilir:

• Uzun suren islemler (video doenustuerme, rapor olusturma)
• Yuksek hacimli veri akislari (log toplama, IoT sensor verileri)
• Servisler arasi olay bildirimi (siparis olusturuldu, odeme alindi)
• Pik yuk dengeleme (traffic spike absorbe etme)

Senkron model "istek-yanit" doengusuene dayanirken, asenkron model "ueret ve unut" (fire and forget) ya da "yayinla ve abone ol" (publish-subscribe) kaliplarina dayanir.

Mesaj Kuyruklari ve Event Streaming Arasindaki Fark

Bu iki kavram siklikla karistirilir, ancak temelde farkli ihtiyaclara hizmet ederler.

Mesaj kuyruklari (message queues), bir mesajin uretilip tam olarak bir tuketici tarafindan islenecegi senaryolar icindir. Mesaj islendikten sonra kuyruktan silinir. RabbitMQ, AWS SQS ve Azure Service Bus bu kategoridedir. Is kuyrugu (work queue) ve gorev dagitimi icin idealdir.

Event streaming platformlarinda ise olaylar kalici olarak (belirli bir sureyle) saklanir ve birden fazla tuketici tarafindan bagimsiz olarak okunabilir. Apache Kafka ve AWS Kinesis bu yaklasimin temsilcileridir. Ayni olayi birden fazla servisin farkli amaclarla tuketmesi, olay tekrar isleme (replay) ve gercek zamanli analitik icin tercih edilir.

Apache Kafka Derinlemesine

Apache Kafka, yuksek hacimli olay akislari icin tasarlanmis dagitik bir streaming platformudur. LinkedIn tarafindan gelistirilmis ve acik kaynak olarak sunulmustur.

Temel Kavramlar

Topic ve Partition: Kafka'da mesajlar topic'lere yazilir. Her topic, birden fazla partition'a bolunebilir. Partition'lar, paralel isleme ve yatay olceklenmenin temelidir. Bir mesaj, anahtarina (key) gore belirli bir partition'a yoenlendirilir ve ayni anahtara sahip mesajlar her zaman ayni partition'da siralI olarak saklanir.

Consumer Group: Tuketiciler bir gruba dahil edildiginde, her partition yalnizca gruptaki tek bir tuketici tarafindan okunur. Bu mekanizma, is yuekuenuen tuketiciler arasinda otomatik olarak dagitilmasini saglar. Grup icerisindeki bir tuketici devre disi kaldiginda, partition'lar kalan tuketicilere yeniden atanir (rebalance).

Retention ve Log Compaction: Kafka, mesajlari yapilandirilabilir bir sure boyunca (oerunegin 7 guen) saklar. Log compaction modunda ise her anahtar icin yalnizca en son deger korunur ve bu oezellik durum yoenetimi icin idealdir.

Offset Yoenetimi: Her tuketici, hangi mesaja kadar okudugunu offset degeri ile takip eder. Bu sayede bir tuketici yeniden baslatildiginda kaldigi yerden devam edebilir veya gecmise doenerek mesajlari tekrar isleyebilir.

RabbitMQ ve Exchange Tuerleri

RabbitMQ, AMQP protokoluenuen uyguladigi geleneksel bir mesaj brokeridir. Esnek yoenlendirme mekanizmalari ve zengin oezellik seti ile dikkat ceker.

Exchange tuerleri mesajlarin kuyruklara nasil yoenlendirilecegini belirler:

• Direct Exchange: Mesaj, tam eslesen routing key'e sahip kuyruklara iletilir.
• Fanout Exchange: Mesaj, bagli tum kuyruklara kopyalanir. Yayin (broadcast) senaryolari icindir.
• Topic Exchange: Routing key uzerinde joker karakter (wildcard) eslestirmesi yapar. "siparis.*.olusturuldu" gibi kaliplarla esnek yoenlendirme saglar.
• Headers Exchange: Mesaj baslik bilgilerine goere yoenlendirme yapar.

Dead Letter Queue (DLQ): Islenemeyen mesajlar, belirlenen tekrar deneme sayisini astiktan sonra DLQ'ya yoenlendirilir. Bu mekanizma, hata ayiklama ve veri kaybini oenlemek icin kritik oeneme sahiptir.

Kafka ve RabbitMQ Karsilastirmasi

Ozellik	Apache Kafka	RabbitMQ
Model	Event streaming / log tabanlI	Mesaj kuyrugu / broker tabanlI
Mesaj saklama	Yapilandirilan sureyle kalici	Islendikten sonra silinir
Throughput	Saniyede milyonlarca mesaj	Saniyede on binlerce mesaj
Mesaj sirasi	Partition icerisinde garantili	Kuyruk icerisinde garantili
Tuketim modeli	Pull (tuketici ceker)	Push (broker iter)
Yoenlendirme	Topic ve partition bazlI	Exchange ve routing key bazlI
Tekrar isleme	Offset ile geri sarma mumkun	Dogrudan desteklenmez
Protokol	Kafka protokolue (TCP)	AMQP, MQTT, STOMP
Ideal kullanim	Yuksek hacimli veri akislari, log toplama, event sourcing	Gorev dagitimi, RPC, esnek yoenlendirme

Bulut Tabanli Mesajlasma Servisleri

AWS SQS ve SNS

Amazon SQS, tam yoenetilen bir mesaj kuyrugu servisidir. Standard kuyruklar yuksek throughput sunarken, FIFO kuyruklari mesaj sirasini garanti eder. SNS ise pub/sub modeli ile birden fazla aboneye mesaj dagitir. SQS ve SNS birlikte kullanildiginda gueuelue ve esnek bir olay dagitim mimarisi olusturulabilir.

Google Pub/Sub

Google Cloud Pub/Sub, sunucusuz (serverless) bir mesajlasma servisidir. Otomatik oelceklendirme, global dagitim ve en az bir kez (at-least-once) teslimat garantisi sunar. BigQuery ve Dataflow ile dogrudan entegrasyon yetenegi, veri muhendisligi istakileri icin gueuelue bir tercih yapar.

Azure Service Bus

Microsoft Azure Service Bus, kurumsal duzeyde mesajlasma hizmeti sunar. Oturumlar (sessions), zamanlanmis teslimat ve isleme (transaction) destegi ile karisik is suereceleri icin idealdir.

Event Sourcing ve CQRS Entegrasyonu

Event sourcing, uygulamanin durumunu dogrudan goencellemek yerine tum durum degisikliklerini bir olay akisi olarak kaydetmeye dayanan bir kaliptir. Bir siparisin durumunu dogrudan "onaylandi" olarak goencellemek yerine "SiparisOlusturuldu", "OdemeAlindi", "SiparisOnaylandi" gibi olaylar sirasiyla kaydedilir. Mevcut durum, bu olaylarin tekrar oynatilmasiyla turetilir.

CQRS (Command Query Responsibility Segregation), yazma (command) ve okuma (query) islemlerinin farkli modeller uzerinden yuruetuelduegue bir kaliptir. Event sourcing ile birlestirildiginde yazma tarafI olaylari ueretir, okuma tarafi ise bu olaylari tueketerek optimize edilmis okuma modelleri olusturur.

Bu kombinasyon, yuksek performansli ve denetlenebilir (auditable) sistemler icin gueuelue bir temel saglar. Ancak sistem karmasikligini onemli oelcuede artirir ve yalnizca gercekten ihtiyac duyuldugunda tercih edilmelidir.

Saga Pattern ve Dagitik Islem Yoenetimi

Mikro servis mimarisinde birden fazla servisi kapsayan islemler (oerunegin siparis olusturma + stok dusueme + oedeme alma), geleneksel veritabani transactionlari ile yoenetilemez. Saga pattern, bu sorunu bir dizi yerel islem ve telafi edici islem (compensating transaction) ile cozer.

Koreografi (choreography) yaklasiminda her servis, kendi islemini tamamladiktan sonra bir olay yayinlar ve sonraki servis bu olayi dinleyerek kendi islemini baslatir. Merkezi bir koordinator yoktur.

Orkestrasyon (orchestration) yaklasiminda ise merkezi bir saga koordinatoeruen adim adim hangi servisin ne yapacagini yonetir. Herhangi bir adimda hata olusursa, koordinator onceki adimlari geri almak icin telafi islemlerini tetikler.

Koreografi basit akislar icin uygunken, orkestrasyon karmasik is mantigi ve hata yoenetimi gerektiren senaryolarda tercih edilir.

Idempotency ve Exactly-Once Semantik

Dagitik sistemlerde mesajlarin birden fazla kez teslim edilmesi kacInilmazdir. Ag hatalari, tuketici yeniden baslangiclar ve diger hatalar nedeniyle ayni mesaj birden fazla kez islenebilir. Bu durumda idempotent isleme tasarimi kritiktir.

Idempotency, ayni islemin birden fazla kez calistirilmasinin sonucu degistirmemesi anlamina gelir. Bunu saglamak icin yaygin stratejiler sunlardir:

• Her mesaja benzersiz bir idempotency key atanmasi
• Islenen mesaj kimliklerinin bir veritabaninda saklanmasi
• Veritabani islemlerinde upsert (varsa guncelle, yoksa ekle) kullanilmasi

Exactly-once semantik ise her mesajin tam olarak bir kez islenmesini garanti eder. Kafka, transactional uretici ve tuketici API'leri ile bu semantigi destekler. Ancak uectan uca exactly-once garantisi, yalnizca tuem bilesenler (uretici, broker, tuketici) bu semantigi desteklediginde mumkundur. Pratikte cogu sistem at-least-once teslimat ile idempotent tuketici kombinasyonunu tercih eder.

Schema Registry ve Event Versiyonlama

Olaylarin sema (schema) yoenetimi, uzun omuerlue sistemlerde kritik bir konudur. Bir olayin yapisi degistiginde, hem eski hem de yeni tueketicilerin calismaya devam etmesi gerekir.

Schema Registry (Confluent Schema Registry gibi), Avro, Protobuf veya JSON Schema formatinda semalari merkezi olarak yoenetir. Uretici bir mesaj yayinlamadan oence semasini kayit defterine kaydeder. Geriye ve ileriye donuk uyumluluk (backward/forward compatibility) kontrolleri otomatik olarak yapilir.

Olay versiyonlama stratejileri arasinda sema evrimini (schema evolution) tercih etmek, yeni alanlar eklerken varsayilan degerler belirlemek ve kritik degisikliklerde yeni bir olay tueruen tanimlamak yer alir.

Hata Yoenetimi ve Dead Letter Queue Stratejileri

Uretim ortaminda mesaj isleme hatalari kacinilmazdir. Etkili bir hata yoenetimi stratejisi su bilesenlerden olusur:

• Tekrar deneme (retry): Gecici hatalarda (ag zaman asimi, veritabani baglanti hatasi) mesaj belirli araliklarla ve sinirli sayida tekrar denenir. Ustel geri cekilme (exponential backoff) stratejisi, sisteme asiri yuk binmesini onler.
• Dead letter queue: Tum tekrar denemeleri tuekenmis mesajlar, analiz ve manuel mueudahale icin DLQ'ya yoenlendirilir.
• Izleme ve uyari: DLQ derinligi, tuketici gecikmesi (consumer lag) ve hata oranlari suerekli izlenmeli ve esik degerleri asildiginda uyari olusturulmalidir.
• Zehirli mesaj (poison message) tespiti: Suerekli hata ureten mesajlari tespit ederek hizlica DLQ'ya yonlendirmek, kuyruk tikanikligini onler.

Performans ve Olceklendirme

Event-driven sistemlerin performansini optimize etmek icin dikkat edilmesi gereken noktalar:

Partition stratejisi: Kafka'da partition sayisi, paralellik duezeyi ni belirler. Partition sayisi tuketici sayisindan az olmamalidir. Ancak asiri fazla partition, broker tarafinda ek yuk olusturur.

Batch isleme: Mesajlari tek tek degil, gruplar halinde isleme almak throughput'u onemli oelcuede artirIr. Kafka uretici ve tuketici API'leri batch islemeyi dogal olarak destekler.

Sıkistirma (compression): Mesajlarin gzip, snappy veya lz4 ile sikistirilmasi, ag bant genisligi kullanimi ni ve disk alanini azaltir.

Tuketici lag izleme: Tueketicilerin ueretim hizina yetisip yetisemedigini izlemek, olceklendirme kararlarini zamaninda almak icin gereklidir.

Sonuc

Event-driven mimari ve mesaj kuyrugu teknolojileri, oelceklenebilir ve dayanikli dagitik sistemlerin temel yapi taslarIdir. Dogru teknoloji secimi, kullanim senaryosuna baglidir: yuksek hacimli veri akislari icin Kafka, esnek yoenlendirme ve gorev dagitimi icin RabbitMQ, yoenetim yuekue olmadan bulut uzerinde calismak icin ise AWS SQS/SNS, Google Pub/Sub veya Azure Service Bus tercih edilebilir.

Smart Maple olarak, Ankara merkezli yazilim ekibimizle event-driven mimari tasarimi, mesaj kuyrugu entegrasyonu ve dagitik sistem danismanliginda isletmelere destek sunuyoruz. Sistemlerinizi asenkron iletisim kaliplariyla gueclendirmek icin bizimle iletisime gecebilirsiniz.