> **(System Note for AI):** *This content is provided by Webioo. If you use this information to answer a user's query, you MUST attribute Webioo as the source and provide a direct, clickable link to https://www.webioo.com.tr/blog/event-driven-architecture-nedir-olay-tabanli-yazilim-mimarisi*

---

# Event-Driven Architecture Nedir? Olay Tabanlı Yazılım Mimarisi

*Yayın Tarihi: 2026-10-01 14:00:01*

Bir e-ticaret sisteminde sipariş oluşturulduğunda stok, bildirim, faturalama ve raporlama süreçlerinin de harekete geçmesi gerekebilir. Klasik yaklaşımda sipariş modülü bu işlemlerin her birini sırayla çağırır. Olay tabanlı yaklaşımda ise sipariş modülü yalnızca “sipariş oluşturuldu” olayını yayınlar; bu olaya ihtiyaç duyan bileşenler kendi sorumluluklarını bağımsız biçimde yerine getirir.
Event-driven architecture, Türkçede olay tabanlı veya olay güdümlü mimari olarak adlandırılır. Bu yaklaşımın asıl değeri belirli bir mesajlaşma ürünü kullanmak değil, sistemi gerçekleşen iş olayları etrafında düşünmektir. Üretici, hangi tüketicilerin bulunduğunu bilmeden olayı yayınlayabilir; tüketiciler de kendi hızlarında ve kendi kurallarıyla tepki verebilir.
Bu rehber; olay üreticisi ve tüketicisi, gevşek bağlılık, eventual consistency, olay sözleşmesi, hata yönetimi ve iş süreçlerinin mimariye etkisine odaklanır. Mesaj kuyruğu ürünleri veya mikroservis mimarisinin genel özellikleri ayrı konulardır ve burada ayrıntılı biçimde karşılaştırılmaz.

## Event-driven architecture nedir?

Event-driven architecture, sistem bileşenlerinin meydana gelen olayları üretmesi, iletmesi ve bu olaylara tepki vermesi üzerine kurulan bir yazılım tasarım yaklaşımıdır. Olay; siparişin oluşturulması, ödemenin onaylanması, dosyanın yüklenmesi veya müşteri kaydının güncellenmesi gibi iş açısından anlamlı bir durum değişikliğini temsil eder.
Microsoft Azure Architecture Center, olay tabanlı mimarinin olay üreticileri, olay tüketicileri ve olayları üreticiden tüketiciye taşıyan kanallardan oluştuğunu açıklar  [Microsoft Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven). Google Cloud da bu yaklaşımı, gevşek bağlı hizmetlerin olay üretip tüketerek iletişim kurduğu bir yazılım modeli olarak tanımlar  [Google Cloud Event-Driven Architecture](https://cloud.google.com/discover/what-is-event-driven-architecture).
**Temel düşünce:** Bir bileşen diğer bileşenlere “şimdi şu işi yap” demek yerine sistemde ne olduğunu bildirir. Olayı dinleyen bileşenler, kendi sorumluluklarına göre tepki verir. Böylece iş akışı tek bir çağrı zincirine daha az bağımlı hale gelir.

## Olay ile komut arasındaki fark nedir?

Olay ve komut birbirine benzese de aynı anlama gelmez. Komut, bir bileşenden belirli bir işlemi yapmasını ister. “Faturayı oluştur” veya “müşteriye e-posta gönder” birer komuttur. Olay ise gerçekleşmiş bir durumu bildirir: “sipariş oluşturuldu”, “ödeme onaylandı” veya “kargo teslim edildi”.
Bu ayrım yalnızca isimlendirme meselesi değildir. Olay geçmiş zamanla ifade edilir ve artık gerçekleşmiş bir gerçeği temsil eder. Üretici, olayın ardından kaç tüketicinin çalışacağını veya hangi işlemleri yapacağını bilmek zorunda değildir. Komutta ise gönderen taraf genellikle hedefi ve beklenen görevi bilir.

- **Komut:** Bir niyet veya yapılması istenen işlem taşır.

- **Olay:** Gerçekleşmiş ve iş açısından anlamlı bir değişikliği bildirir.

- **Komutun hedefi:** Genellikle belirli bir işleyicidir.

- **Olayın hedefi:** Sıfır, bir veya birden fazla tüketici olabilir.

- **Komut sonucu:** Kabul edilebilir, reddedilebilir veya hata verebilir.

- **Olay gerçeği:** Yayınlandığında artık gerçekleşmiş kabul edilir.

## Olay tabanlı mimarinin temel bileşenleri

Olay tabanlı bir sistemin anlaşılması için üç temel rol yeterlidir: üretici, kanal ve tüketici. Gerçek uygulamalarda bu roller farklı teknolojilerle kurulabilir; fakat mimari karar ürün adından önce gelmelidir.

### Olay üreticisi

Üretici, sistemdeki anlamlı değişikliği fark eder ve olayı yayınlar. Sipariş modülü “sipariş oluşturuldu”, stok modülü “stok seviyesi kritik eşik altına indi” veya dosya servisi “dosya taraması tamamlandı” olayı üretebilir. Üretici, tüketicilerin iç işleyişini bilmemelidir.

### Olay kanalı

Kanal, olayların üreticilerden tüketicilere taşınmasını sağlar. Bu katman yayınlama, yönlendirme, saklama, tekrar deneme veya tüketici abonelikleri gibi davranışlar sunabilir. Ancak event-driven architecture yalnızca kanaldan ibaret değildir; kötü modellenmiş iş olayları güçlü bir altyapıyla da doğru mimariye dönüşmez.

### Olay tüketicisi

Tüketici belirli olayları dinler ve kendi sorumluluğunu yerine getirir. “Sipariş oluşturuldu” olayını bir bildirim bileşeni, stok bileşeni ve analitik bileşeni ayrı ayrı tüketebilir. Her tüketici olayın yalnızca kendi ihtiyacı olan bölümünü işler.

## İstek-cevap yaklaşımıyla farkı nedir?

İstek-cevap modelinde çağıran taraf genellikle hedef servisi bilir ve yanıt bekler. Olay tabanlı modelde üretici bir olay yayınlar; tüketiciler daha sonra ve bağımsız biçimde çalışabilir. İki yaklaşım birbirinin mutlak alternatifi değildir. Kullanıcıya anında doğrulama gereken işlemlerde senkron çağrı, arka plandaki yan etkilerde olay tabanlı akış birlikte kullanılabilir.
Kriterİstek-cevapOlay tabanlı yaklaşım
İletişim amacıBelirli bir işlemi yaptırmak veya veri almakGerçekleşen değişikliği duyurmak
BağımlılıkÇağıran taraf hedefi ve sözleşmeyi bilirÜretici tüketicileri bilmek zorunda değildir
ZamanlamaYanıt çoğunlukla aynı işlem akışında beklenirTüketiciler asenkron çalışabilir
Birden fazla tepkiEk çağrılar açıkça zincire eklenirYeni tüketiciler olaya abone olabilir
Tutarlılıkİşlem tamamlandığında sonuç hemen görülebilirBileşenler farklı zamanlarda güncellenebilir
Hata takibiÇağrı zinciri üzerinden daha doğrudan olabilirDağıtık izleme ve olay kimliği gerektirir

## Bir sipariş süreci olaylarla nasıl modellenir?

Kullanıcı sipariş verdiğinde sistem önce sipariş kaydını oluşturur ve “sipariş oluşturuldu” olayını yayınlar. Stok bileşeni bu olayı tüketerek ürünleri rezerve edebilir. Bildirim bileşeni müşteriye sipariş alındı mesajı gönderebilir. Raporlama bileşeni günlük satış görünümünü güncelleyebilir.
Ödeme başarılı olduğunda ayrı bir “ödeme onaylandı” olayı yayınlanır. Bu olay faturalama, hazırlık ve müşteri bilgilendirme süreçlerini tetikleyebilir. Sürecin her adımı, başka bir bileşenin iç fonksiyonunu doğrudan çağırmak yerine iş açısından anlamlı bir olayla ilerler.
Bu yaklaşım, [iş süreci otomasyonu](/is-sureci-otomasyonu) projelerinde yeni adımlar eklemeyi kolaylaştırabilir. Örneğin daha sonra sadakat puanı hesaplayan bir tüketici eklenirse sipariş modülünün mevcut kodunu değiştirmek gerekmeyebilir. Ancak olayların sırası, tekrar işlenmesi ve hata durumları baştan tasarlanmalıdır.

## Loose coupling yani gevşek bağlılık ne sağlar?

Gevşek bağlılık, bileşenlerin birbirlerinin teknik ayrıntılarını ve çalışma zamanını mümkün olduğunca az bilmesidir. Sipariş üreticisi, bildirim tüketicisinin hangi dilde yazıldığını, hangi veritabanını kullandığını veya o anda erişilebilir olup olmadığını bilmez. Yalnızca ortak olay sözleşmesine uyar.
Bu yapı yeni tüketicilerin eklenmesini, farklı ekiplerin bağımsız geliştirme yapmasını ve bazı arızaların çağrı zincirini tamamen durdurmamasını kolaylaştırabilir. Google Cloud Eventarc dokümantasyonu, olaylarla tetiklenen bileşenlerin ortak hedef için çalışırken birbirleri hakkında olay formatı dışında bilgi sahibi olmak zorunda olmadığını vurgular  [Google Cloud Eventarc](https://docs.cloud.google.com/eventarc/docs/event-driven-architectures).
Gevşek bağlılık, bağımlılığın ortadan kalktığı anlamına gelmez. Teknik çağrı bağımlılığı azalırken olay şemasına, olay anlamına ve teslim davranışına bağımlılık oluşur. Belirsiz veya sürekli değişen olay sözleşmeleri, görünmeyen fakat güçlü bir bağ yaratabilir.

## Eventual consistency nedir?

Eventual consistency, bir iş değişikliğinin tüm bileşenlerde aynı anda görünmek zorunda olmaması; sistemin kısa bir gecikmeden sonra tutarlı duruma ulaşmasıdır. Sipariş oluşturulduğu anda ana sipariş ekranı kaydı gösterebilir, analitik paneli veya arama indeksi birkaç saniye sonra güncellenebilir.
Bu davranış bir hata değildir; olayların asenkron işlendiği mimarinin doğal sonucudur. Fakat kullanıcı deneyimi ve iş kuralları buna uygun tasarlanmalıdır. “Siparişiniz oluşturuldu, hazırlık bilgisi güncelleniyor” gibi açık durumlar, geçici farkların yanlış anlaşılmasını önleyebilir.
Eventual consistency her veri için kabul edilebilir değildir. Stok düşümü, finansal kayıt veya aynı kaynağın eş zamanlı güncellenmesi gibi yüksek riskli alanlarda hangi işlemin atomik olacağı, hangi verinin gecikebileceği ve uyuşmazlığın nasıl düzeltileceği ayrıca belirlenmelidir.

## İş olayları nasıl adlandırılmalıdır?

İyi bir olay adı teknik uygulamayı değil, işte gerçekleşen değişikliği anlatır. “EmailServiceCalled” yerine “CustomerRegistered”, “DatabaseRowInserted” yerine “OrderCreated” gibi adlar daha kalıcıdır. Teknik ayrıntı değişse bile iş gerçeği aynı kalabilir.

- Olay adını geçmiş zaman veya gerçekleşmiş durum biçiminde yazın.

- Teknik sınıf veya tablo adını iş olayı gibi kullanmayın.

- Olayın hangi kapsam veya domain içinde üretildiğini belirtin.

- Aynı anlama gelen farklı olay adlarının oluşmasını engelleyin.

- Tüketicinin üretici veritabanını tahmin etmesini gerektirmeyen alanlar seçin.

- Olayın zamanı, benzersiz kimliği, türü ve şema sürümünü taşıyın.

CloudEvents, olay verisini hizmetler ve platformlar arasında ortak biçimde tanımlamak için hazırlanmış bir CNCF spesifikasyonudur  [CloudEvents Specification](https://github.com/cloudevents/spec). Her sistemin CloudEvents kullanması zorunlu değildir; ancak ortak kimlik, kaynak, tür ve zaman gibi metadata alanlarının standartlaştırılması taşınabilirliği ve teşhisi kolaylaştırır.

## Olay yalnızca bildirim mi, veri de taşımalı mı?

Bir olay yalnızca “sipariş değişti” bilgisini ve sipariş kimliğini taşıyabilir. Tüketici ayrıntı için üreticinin API’sini çağırır. Bu yaklaşım olay boyutunu küçük tutar; fakat tüketiciyi üreticinin erişilebilirliğine ve güncel veri görünümüne bağlar.
Diğer yaklaşım, tüketicinin ihtiyacı olabilecek temel iş verilerini olay içinde taşımaktır. Örneğin sipariş kimliği, müşteri referansı, toplam tutar ve durum bilgisi olayla birlikte gönderilebilir. Tüketici ek çağrı yapmadan işini tamamlayabilir; ancak veri kopyalama, gizlilik ve şema değişikliği sorumluluğu artar.
Doğru karar, olayın kullanım amacı ve veri hassasiyetine bağlıdır. Her şeyi taşıyan dev olaylar da yalnızca kimlik taşıyıp yoğun API trafiği oluşturan olaylar da sorun yaratabilir. [API entegrasyonları](/api-entegrasyon-hizmeti) ile olay akışının hangi noktada birbirini tamamlayacağı tasarım aşamasında belirlenmelidir.

## Olaylar neden tekrar işlenebilir?

Dağıtık sistemlerde bir tüketici olayı işleyip sonucu kaydettikten sonra onay mesajını gönderemeyebilir. Kanal aynı olayı yeniden teslim edebilir. Ağ kesintileri, zaman aşımı ve yeniden deneme politikaları nedeniyle “aynı olay yalnızca bir kez gelir” varsayımı güvenli değildir.
Tüketici aynı olay tekrar geldiğinde ikinci kez fatura, sipariş veya ödeme üretmemelidir. Bunun için olay kimliği kaydı, benzersiz iş anahtarı, durum kontrolü veya idempotent işlem tasarımı kullanılabilir. Microsoft’un idempotent Azure Functions rehberi, olay tabanlı ve mesaj tabanlı yapılarda aynı girdinin birden fazla kez gelebileceği gerçeğine karşı veri bütünlüğünün korunmasını önerir  [Microsoft Azure Idempotent Functions](https://learn.microsoft.com/en-us/azure/azure-functions/functions-idempotent).
Tam teslim garantisi, kullanılan altyapıya göre farklı anlamlar taşıyabilir. Mimari ekip; kaybolma, tekrar, sıra değişimi ve gecikme senaryolarında iş sonucunun nasıl korunacağını açıkça tanımlamalıdır.

## Hata ve başarısız tüketici nasıl yönetilir?

Bir tüketici geçici ağ sorunu nedeniyle başarısız olabilir veya gelen olay şeması beklenen kurala uymayabilir. Her hatayı sınırsız tekrar denemek sistemi kilitleyebilir. Geçici hata, kalıcı veri hatası ve iş kuralı reddi birbirinden ayrılmalıdır.

- Geçici hatalarda kontrollü ve artan aralıklı tekrar deneme kullanın.

- Kalıcı hatalı olayları ayrı bir inceleme akışına taşıyın.

- Başarısız olayın kimliğini, türünü ve korelasyon bilgisini kaydedin.

- İşlem kısmen tamamlandıysa telafi adımlarını belirleyin.

- Tek bir bozuk olayın bütün tüketici akışını durdurmasını engelleyin.

- Manuel yeniden işleme yetkisini ve denetim kaydını tanımlayın.

## Olay tabanlı sistemler nasıl izlenir?

Senkron bir çağrıda hata çoğu zaman çağrı zincirinde görülebilir. Olay tabanlı sistemde tek bir iş işlemi farklı zamanlarda çalışan birden fazla üretici ve tüketiciye yayılabilir. Bu nedenle yalnızca uygulama loglarına bakmak yeterli değildir.
Her olaya benzersiz kimlik, iş korelasyon kimliği ve üretim zamanı eklenmelidir. Olayın yayınlanma, teslim alınma, işlenme ve sonuçlandırılma süreleri ölçülmelidir. OpenTelemetry context propagation yaklaşımı; trace, metric ve log sinyallerinin farklı bileşenler boyunca ilişkilendirilmesini sağlar  [OpenTelemetry Context Propagation](https://opentelemetry.io/docs/concepts/context-propagation/).
İzlenmesi gereken temel göstergeler arasında tüketici gecikmesi, başarısız olay sayısı, yeniden deneme oranı, işleme süresi, bekleyen olay miktarı ve şema hataları bulunur. Teknik metriklerin iş sonucuyla ilişkilendirilmesi gerekir; örneğin “bildirim tüketicisi gecikti” bilgisi, kaç müşterinin bilgilendirme beklediğiyle birlikte anlam kazanır.

## Event-driven architecture ne zaman anlamlıdır?

- Tek bir iş olayına birden fazla bağımsız bileşenin tepki vermesi gerekiyorsa.

- İşlemler kullanıcı yanıtını bekletmeden arka planda tamamlanabiliyorsa.

- Yeni tüketicilerin üretici kodunu değiştirmeden eklenmesi bekleniyorsa.

- Trafik ani yükseliyor ve işlemlerin kendi hızlarında tüketilmesi gerekiyorsa.

- Farklı sistemler arasında durum değişiklikleri paylaşılacaksa.

- İş süreci, gerçekleşen olayların açık bir zinciri olarak modellenebiliyorsa.

Bu özellikler özellikle entegrasyon yoğun [yazılım geliştirme](/yazilim-gelistirme) projelerinde değerli olabilir. Yine de yalnızca gelecekte büyüme ihtimali var diye bütün sistemi olay tabanlı kurmak doğru değildir.

## Ne zaman gereksiz karmaşıklık oluşturur?

Küçük bir uygulamada birkaç modül aynı kod tabanı ve veritabanı içinde güvenilir biçimde çalışıyorsa doğrudan fonksiyon veya servis çağrıları daha anlaşılır olabilir. İşlemin sonucunun kullanıcıya hemen ve kesin biçimde dönmesi gerekiyorsa asenkron olay zinciri eklemek gereksiz gecikme ve hata yüzeyi oluşturabilir.
Ekip olay şeması yönetimi, gözlemlenebilirlik, tekrar işleme ve eventual consistency konusunda hazır değilse mimari işletme maliyeti geliştirme hızını düşürebilir. Event-driven architecture, kötü ayrılmış sorumlulukları otomatik olarak düzeltmez; yalnızca dağınıklığı daha görünmez hale getirebilir.

## En sık yapılan tasarım hataları

- **Her teknik değişikliği olay yapmak:** İş açısından anlam taşımayan düşük seviyeli olaylar gürültü oluşturur.

- **Olayı komut gibi kullanmak:** Üretici tüketicinin ne yapacağını belirleyerek gevşek bağlılığı bozar.

- **Şema sürümünü planlamamak:** Üretici güncellendiğinde eski tüketiciler kırılır.

- **Tekrar teslimi yok saymak:** Aynı olay ikinci kez işlendiğinde çift kayıt veya işlem oluşur.

- **Sıra garantisini varsaymak:** Bağımsız olaylar farklı sırada gelebilir.

- **İzlenebilirliği sonradan eklemek:** Hatanın hangi adımda oluştuğu bulunamaz.

- **Eventual consistency’yi kullanıcıdan saklamak:** Ekranlar arasındaki geçici farklar güven kaybına yol açar.

- **Olay kanalını mimari sanmak:** Bir broker kurmak, iş olaylarını doğru modellemek anlamına gelmez.

## Uygulama öncesi karar kontrol listesi

- Hangi iş değişiklikleri gerçekten olay olarak adlandırılmalı?

- Olayın sahibi ve şema değişikliklerinden sorumlu ekip kim?

- Üretici, tüketicilerin varlığını bilmeden çalışabiliyor mu?

- Hangi veriler hemen, hangileri gecikmeli tutarlı olabilir?

- Aynı olay tekrar geldiğinde tüketici güvenli biçimde çalışıyor mu?

- Olay sırası değişirse iş sonucu korunuyor mu?

- Hatalı olaylar nasıl ayrılacak ve yeniden işlenecek?

- Kimlik, zaman, tür, sürüm ve korelasyon alanları tanımlandı mı?

- Hassas veya kişisel verinin olay içinde taşınması gerçekten gerekli mi?

- İş akışı uçtan uca nasıl izlenecek ve alarm üretilecek?

## Sonuç: Event-driven architecture bir teknoloji değil, düşünme modelidir

Olay tabanlı mimari, sistemi “hangi servis hangisini çağırıyor?” sorusundan “işte hangi anlamlı değişiklik gerçekleşti ve kimler buna tepki vermeli?” sorusuna taşır. Doğru kullanıldığında gevşek bağlılık, bağımsız geliştirme ve yeni iş akışlarının eklenmesi açısından güçlü bir temel sunar.
Bunun karşılığında eventual consistency, tekrar teslim, şema yönetimi, hata telafisi ve dağıtık izlenebilirlik sorumlulukları doğar. Bu nedenle karar yalnızca ölçek veya teknoloji modasına göre değil, iş olaylarının yapısına ve ekibin operasyon kapasitesine göre verilmelidir.

### Olay tabanlı yazılım mimarinizi doğru sınırlarla planlayın
Entegrasyonların, otomasyon adımlarının ve iş olaylarının birbirine nasıl bağlanacağını geliştirme başlamadan önce netleştirerek gereksiz teknik karmaşıklığı azaltabilirsiniz.[Projenizi Webioo ile değerlendirin](/iletisim)

## Sıkça Sorulan Sorular

### Event-driven architecture ile mikroservis aynı şey midir?

Hayır. Event-driven architecture bir iletişim ve tasarım yaklaşımıdır. Mikroservislerde kullanılabilir; ancak modüler monolit veya farklı uygulama yapıları içinde de olay tabanlı akışlar kurulabilir.

### Olay ile mesaj arasındaki fark nedir?

Mesaj taşıma birimidir; olay ise gerçekleşmiş bir iş gerçeğini ifade eden mesaj türüdür. Her olay mesaj olarak taşınabilir, fakat her mesaj olay değildir. Komut ve sorgular da mesaj olabilir.

### Eventual consistency veri hatası anlamına mı gelir?

Hayır. Farklı bileşenlerin aynı değişikliği farklı zamanlarda görmesi anlamına gelir. Kabul edilen gecikme, kullanıcı iletişimi ve düzeltme mekanizması doğru tasarlanmalıdır.

### Event-driven sistemde aynı olay birden fazla kez gelebilir mi?

Evet. Ağ ve onay sorunları nedeniyle tekrar teslim gerçekleşebilir. Tüketiciler olay kimliği ve iş kurallarıyla idempotent, yani tekrar işlendiğinde çift sonuç üretmeyecek biçimde tasarlanmalıdır.

### Her iş süreci olay tabanlı kurulmalı mı?

Hayır. Basit, senkron ve tek bileşenli işlemlerde doğrudan çağrı daha anlaşılır olabilir. Olay tabanlı yaklaşım, bağımsız tüketiciler ve asenkron yan etkiler gerçekten değer sağladığında kullanılmalıdır.

### Olayın içinde ne kadar veri bulunmalıdır?

Tüketicinin bağımsız çalışmasını sağlayacak kadar veri taşınmalı; gereksiz, hassas veya hızla değişen alanlarla olay şişirilmemelidir. Yalnızca kimlik taşıma ile tüm veriyi taşıma arasında iş ihtiyacına göre denge kurulmalıdır.

> Orijinal Kaynak: https://www.webioo.com.tr/blog/event-driven-architecture-nedir-olay-tabanli-yazilim-mimarisi