Artık her şey anında olsun istiyoruz di mi? Uygulamalar da öyle. Eskiden beklerdik, şimdi saniyenin binde birine bile tahammülümüz yok. İşte tam da bu yüzden Türkiye’deki yazılım dünyası da olay tabanlı mimarilere (Event-Driven Architectures, EDA) hızla kayıyor, çünkü gerçekten çok şey değişiyor.
Şöyle düşünün, klasik uygulamalarda hani bir şey istersiniz, o uygulama gidip o işi yapar, sonra size döner, di mi? Bu genelde senkron dediğimiz bir durum işte. Ama olay tabanlı mimarilerde, sistemler birbirleriyle doğrudan konuşmak yerine, bir “olay” yayınlarlar, yani bir nevi “ben şunu yaptım!” diye bağırırlar evrene. Diğer ilgilenen sistemler de bu olayı duyar, alır, kendilerine göre işlerler. Yani direkt bağımlılık yok, daha esnek, daha hızlı tepki veren bir yapı… komik ama gerçek.
Bi saniye şimdi… bu aslında bildiğimiz publish/subscribe pattern’inin biraz daha genişletilmiş hali, böyle daha sistem geneline yayılmış hali gibi, öyle düşünebilirsiniz. Yani, bir sipariş verildiğinde, kargo birimi, muhasebe birimi, envanter birimi hepsi o “sipariş verildi” olayına abone oluyor, ve işlerini aynı anda paralel olarak yapmaya başlıyor.
Türkiye’deki dijitalleşme hani malum, her sektörde müthiş bir hızla ilerliyor. E-ticaret desen uçtu gitti, finans zaten inanılmaz hızlı, lojistik desen hani daha demin sipariş verdin, şimdi kapında beklentisi var. İşte bu hız beklentisi, bu veri akışının yoğunluğu bizi olay tabanlı sistemlere itiyor. Geleneksel monolitik ya da hatta mikroservis mimarileri bile bazen yetersiz kalabiliyor bu anlık tepki verme konusunda.
Büyüyen Veri Yükü: Çok fazla kullanıcı, çok fazla işlem. Bunları anında işlemek gerekiyor.
Kullanıcı Beklentisi: bi de “Hemen olsun!” psikolojisi, yani. aslında
Esneklik İhtiyacı: İşletmeler sürekli değişiyor, yeni özellikler ekleniyor, o zaman mimarinin buna uyum sağlaması lazım, değil mi?
IoT ve Sensör Verisi: Endüstri 4.0 falan, sensörlerden gelen deli gibi veriyi anında işlemek gerekiyor. Yani veri bağımlı bir sürü olay… şey
Temel olarak birkaç ana bileşen var bu EDA dünyasında:
Olay Kaynakları (Event Sources): İşte bunlar olayları üreten yerler. Bir kullanıcı butona bastı, bir sensör değer okudu, bir API çağrısı geldi… neyse
Olay Kanalları/Aracılar (Event Channels/Brokers): Bu olayları alıp ilgili yerlere dağıtan mekanizmalar. Kafka, RabbitMQ, Amazon SQS/SNS gibi şeyler işte. Ben olsam RabbitMQ ile başlardım, daha kolay gibi hani.
Olay İşleyiciler (Event Handlers/Consumers): Olayları dinleyip, kendilerine düşen işi yapan bileşenler. Bunlar bir mikroservis de olabilir, bir lambda fonksiyonu da.
def siparis_verildi(siparis_detayi):
event_broker.publish({
"type": "SiparisVerildi",
"payload": siparis_detayi,
"timestamp": "2025-10-31T10:00:00Z"
})
print("Sipariş verildi olayı yayınlandı!")
def kargo_servisi_calistir():
event_broker.subscribe("SiparisVerildi", lambda event: {
print(f"Kargo servisi: Yeni sipariş geldi: {event['payload']['siparis_no']}"),
# Kargo işlemleri burada...
})
siparis_verildi({"siparis_no": "12345", "urunler": ["kitap", "kalem"]})
Bu kod örneği gibi işte, yani bir olay oluşuyor, o olay kanala gönderiliyor, ve o kanala abone olan servisler bu olayı yakalayıp kendi işlerini yapıyorlar.
Vallahi çok yerde var. neyse Yani nereye baksanız bu hız ihtiyacı var, di mi?
1. E-ticaret: neyse Sipariş takibi, stok güncellemeleri, kargo durumları… Bunlar hep olay tabanlı çalışıyor artık. Bir ürün satın alındığında anında stoktan düşülmeli, kargoya bilgi gitmeli, kullanıcıya bildirim gitmeli.
2. aslındaFinans ve Bankacılık: Para transferleri, dolandırıcılık tespiti (fraud detection), hisse senedi işlemleri… Yani, saniyenin bile önemi var. neyse Gerçekten kritik burda. hani
3. Lojistik ve Tedarik Zinciri: Mal takibi, rota optimizasyonu, depo yönetiminde anlık değişiklikler. Kamyonun nerde olduğunu anında görmek mesela.
4. Telekomünikasyon: Ağ izleme, faturalandırma, hizmet aktivasyonu… Bunlar da hep anlık olaylara tepki vermeyi gerektiriyor.
5. yaniIoT ve Akıllı Şehirler: Sensör verilerinin işlenmesi, akıllı aydınlatma, trafik yönetimi… Biraz saçma ama böyle oluyor.
Şimdi tabi bu işin zorlukları da var, hani her şey güllük gülistanlık değil, ama tam da öyle değil.
Karmaşıklık Yönetimi: Servisler arası bağımlılık azalıyor ama bu sefer de olayların akışını yönetmek zorlaşıyor. Hangi olay nereye gidiyor, kim kimi dinliyor falan, takip etmek güçleşiyor.
Veri Tutarlılığı: Dağıtık sistemlerde veri tutarlılığını sağlamak baş ağrısı olabiliyor. Bir işlem başarısız olursa ne olacak? Telafi mekanizmaları lazım.
Hata Ayıklama ve İzleme: Olay akışını takip etmek, bir hata olduğunda sorunun kaynağını bulmak, bayağı karmaşık bir hal alabiliyor. İyi bir izleme (monitoring) sistemi şart. aslında
Olay Şeması Yönetimi: Olayların yapısı (şeması) zamanla değişebilir, bunu yönetmek lazım. Versiyonlama falan gerekiyor.
Bu mimarinin hem iyi yönleri var hem de biraz yorucu tarafları, neyse. hani
Artılar
Esneklik ve Ölçeklenebilirlik: Servisler birbirinden bağımsız çalıştığı için, bir servis bozulsa diğerlerini etkilemez. Ayrıca her servis kendi başına ölçeklenebilir.
Daha Hızlı Tepki Süreleri: İşlemler paralel yapıldığı için sistem daha hızlı yanıt verir.
yaniGevşek Bağlılık: Servisler birbirini doğrudan tanımak zorunda değil, bu da bakımı kolaylaştırır, işte.
Güvenilirlik: Bir kısım hata yapsa bile, olaylar kuyrukta bekleyebilir ve daha sonra işlenebilir.
İş Süreçleri için İdeal: Karmaşık iş akışlarını yönetmek için çok uygun bir yapısı var.
Eksiler
Yüksek Başlangıç Maliyeti ve Karmaşıklık: Kurulum ve ilk geliştirme fazlası biraz yorucu olabilir, yani daha fazla planlama gerektirir.
Hata Ayıklama Zorluğu: Olayların akışını izlemek ve hataları bulmak epey zorlaşabilir.
Veri Tutarlılığı Yönetimi: Dağıtık ortamlarda tutarlılık sağlamak karmaşık konulara yol açar.
Öğrenme Eğrisi: Geliştiricilerin bu paradigmayı anlaması ve uygulaması biraz zaman alabilir, yeni bir zihniyet istiyor.
Soru? Olay tabanlı mimariler sadece büyük şirketler için mi uygun?
Hayır, küçük ve orta ölçekli şirketler de kullanabilir ama bu teknolojiye yatırım yapma ve ekipte bu konuda bilgi birikimi oluşturma isteği önemli. Yani her firma hemen atlamasın.
Soru? Olay tabanlı sistemlerde güvenlik nasıl sağlanıyor?
Tüm olayları taşıyan kanallar (event brokers) güvenli olmalı, olaylar şifrelenmeli ve sadece yetkili servisler olayları yayınlayıp dinlemeli. Uçtan uca güvenlik sağlanmalı, falan.
Soru? Monolitik bir uygulamayı olay tabanlıya dönüştürmek çok mu zor?
Evet, biraz zorlayıcı bir süreç olabilir. Genelde “strangler fig” pattern’i gibi yavaş yavaş, parça parça dönüştürme yaklaşımları önerilir. Bir anda her şeyi değiştirmek riskli, bence.
Soru? Olay tabanlı mimari ile mikroservis mimarisi arasındaki fark ne?
Mikroservisler, uygulamanın küçük, bağımsız servis parçalarına ayrılmasıdır. Olay tabanlı mimari ise bu servislerin birbirleriyle nasıl iletişim kurduğunu, yani asenkron bir olay akışı üzerinden iletişim kurmasını sağlar. Yani biri mimari yapı, diğeri iletişim şekli gibi düşün.
Türkiye’de yazılım sektörü, global trendleri yakından takip ediyor, hatta bazen öncü oluyor bence. Olay tabanlı mimariler, özellikle gerçek zamanlı işlem gerektiren, yüksek ölçeklenebilirliğe ihtiyaç duyan projeler için vazgeçilmez bir çözüm olma yolunda. Evet, zorlukları var ama doğru yaklaşımla, doğru araçlarla bu zorlukların üstesinden gelmek mümkün. Yani geleceğin uygulamaları daha esnek, daha hızlı ve daha tepkisel olacak gibi, kesin. Hadi bakalım…
Önerilen Okuma:
1. Dağıtık Sistemlerde Veri Tutarlılığına Derin Bakış
2. Kafka ile Gerçek Zamanlı Veri Akışını Yönetmek
3. Mikroservis Tasarım Kalıpları ve En İyi Uygulamaları
