---
title: "Event-Driven Mimari: Ne Çözer, Neyi Gizler?"
description: "Event'lerle gevşek bağ kurmanın bedeli: kazandırdığı esneklik ile sistem akışını takip edilemez hale getirme riski arasındaki denge."
url: https://sade.dev/tr/notes/event-driven-mimari-ne-zaman/
lang: tr
author: "Muhammet Şafak"
published: 2026-06-20
updated: 2026-09-06
section: Note
tags: ["architecture","event-driven","messaging"]
summary: "Event'ler, üreticinin tüketicilerini tanımamasını sağlayarak gevşek bağ kazandırır; aynı hamle akışı da görünmez kılar, çünkü bir event kontratını derleyici bir method çağrısı gibi doğrulamaz. İki bedel ya peşin ödenir ya hiç: versiyonlanmış ve şemayla doğrulanan payload, ve her log'a ve her sonraki event'e taşınan bir correlation id. Tek listener'lı bir event, kılık değiştirmiş bir method çağrısıdır."
---

# Event-Driven Mimari: Ne Çözer, Neyi Gizler?

> Event'ler, üreticinin tüketicilerini tanımamasını sağlayarak gevşek bağ kazandırır; aynı hamle akışı da görünmez kılar, çünkü bir event kontratını derleyici bir method çağrısı gibi doğrulamaz. İki bedel ya peşin ödenir ya hiç: versiyonlanmış ve şemayla doğrulanan payload, ve her log'a ve her sonraki event'e taşınan bir correlation id. Tek listener'lı bir event, kılık değiştirmiş bir method çağrısıdır.

"Sipariş oluşturulduğunda ne oluyor?" sorusuna bir ekipte kimsenin net cevap verememesini izledim. Kod tabanında `OrderCreated` event'ini sekiz ayrı listener dinliyordu; hangisinin hangi sırada, hangi koşulda çalıştığı tek bir yerden okunamıyordu. Akış kodda değil, kafalarda — hem de eksik — yaşıyordu.

Event-driven mimari bağı gevşetir. Bu yazı, gevşeyen başka bir şey daha olduğunu hatırlatmak için: nedensellik.

## Event ne çözer?

Bir event yayınlayan kod, onu kimin dinlediğini bilmez. `OrderCreated` yayınlanır; faturalama, bildirim ve analitik onu ayrı ayrı dinler. Sipariş kodu bu üçünden habersizdir.

Kazanç gerçek: yeni bir tüketici eklemek, üreticiye dokunmadan olur. Bağımsız geliştirme, bağımsız dağıtım, fan-out. Birbirini tanımayan parçalar.

## Event neyi gizler?

Aynı madalyonun öbür yüzü: bağ gevşedikçe **akış görünmez olur**.

Doğrudan bir method çağrısında akış kodun kendisidir — tanımına gidersiniz, devamını okursunuz. Event'te öyle değil. `OrderCreated` yayınlandığında ne olduğunu görmek için tüm listener'ları elle bulmanız gerekir. Compiler size yardım etmez: bir method çağrısının kontratını derleyici doğrular, bir event'in kontratını kimse doğrulamaz.

[Modüler monolit yazısındaki](/tr/journal/projelere-neden-moduler-monolit-ile-basliyorum) cümle burada da geçerli — bir network kontratı gibi, bir event kontratı da derleyicinin kör noktasındadır.

## Ödenmeden seçilmemeli: iki ön koşul

Event-driven mimariye geçmeden önce iki bedel peşin ödenir.

**Schema disiplini.** Event bir kontrattır. `OrderCreated`'in payload'ı değiştiğinde, onu dinleyen sekiz yerin haberi olmaz — ta ki production'da kırılana kadar. Event'ler versiyonlanmalı, alanlar geriye uyumlu eklenmeli, payload bir şema ile doğrulanmalı. Bu disiplin yoksa, gevşek bağ "sessiz kırılma" demektir.

**İzlenebilirlik.** Bir isteğin sistemden geçişini görebilmek için her event bir correlation ID taşımalı:

```php
event(new OrderCreated(
    orderId: $order->id,
    correlationId: request()->header('X-Correlation-Id') ?? (string) Str::uuid(),
));
```

Bu ID log'lara ve sonraki event'lere taşınmazsa, çok-listener'lı bir akışta "bu iş neden çalıştı?" sorusunun cevabı yoktur. Tracing, event-driven'ın isteğe bağlı bir eklentisi değil, ön koşuludur.

## Laravel'de: in-process event ≠ event-driven mimari

Laravel'in `event()`/listener mekanizması, senkron çalıştığında aslında düzenlenmiş bir method çağrısıdır — aynı process, aynı transaction, aynı stack trace. Bu güvenli ve izlenebilir; bunu rahatça kullanın.

Event-driven mimarinin getirdiği zorluklar, event bir **sınırı** geçtiğinde başlar: bir queue'ya, bir message broker'a, başka bir process'e. Listener'a `ShouldQueue` ekleyip event'i RabbitMQ'ya gönderdiğiniz an, schema ve tracing borcu devreye girer. İkisini birbirine karıştırmayın: in-process listener kullanmak sizi "event-driven mimariye" geçirmez.

## Ne zaman event-driven'a geçilir?

Event'i gerçekten bir sınırın ötesine taşımak şu durumlarda gerekçeli:

- **Gerçek bir fan-out var.** Bir olayı, birbirini tanımaması gereken çok sayıda bağımsız tüketici dinliyor.
- **Tüketici asenkron olmalı.** İş, üreticinin yanıtını bekletmemeli; "kabul edildi" yeterli.
- **Tüketiciler bağımsız ölçeklenmeli ya da dağıtılmalı.** Bu da bizi [mikroservis kararına](/tr/journal/mikroservise-ne-zaman-gecerim) götürür — aynı ölçülmüş-sinyal eşiği.

Bunlar yoksa, doğrudan bir service çağrısı hem daha okunur hem daha güvenlidir. Tek bir listener'ı olan bir event, sadece kılık değiştirmiş bir method çağrısıdır — üstelik izi sürülmesi daha zor olanı.

---

Event-driven mimari bağı gevşetir; bunu yaparken nedenselliği de gevşetir. Birincisini istiyorsanız, ikincisinin faturasını — schema ve tracing — peşin ödeyin.

Gevşek bağ bedava değildir; görünmez akışla ödenir.

## Sık sorulanlar

**Laravel in-process event kullanmak event-driven mimari sayılır mı?**

Sayılmaz. Senkron bir listener düzenlenmiş bir method çağrısıdır — aynı process, aynı transaction, aynı stack trace — ve güvenli, izlenebilirdir. Zorluklar event bir sınırı geçtiğinde başlar: bir queue'ya, bir broker'a ya da başka bir process'e. Schema ve tracing borcu orada devreye girer.

**Event-driven mimariye geçmeden önce hangi bedel ödenir?**

İki şey, peşin. Schema disiplini: event bir kontrattır; versiyonlanmalı, geriye uyumlu genişletilmeli ve bir şemayla doğrulanmalıdır, yoksa gevşek bağ yalnızca sessiz kırılma demektir. Bir de izlenebilirlik: her event bir correlation id'yi log'lara ve tetiklediği event'lere taşımazsa, bu iş neden çalıştı sorusunun cevabı olmaz.


## Kaynaklar

- [Enterprise Integration Patterns: Publish-Subscribe Channel](https://www.enterpriseintegrationpatterns.com/patterns/messaging/PublishSubscribeChannel.html) — Hohpe and Woolf
- [Enterprise Integration Patterns: Correlation Identifier](https://www.enterpriseintegrationpatterns.com/patterns/messaging/CorrelationIdentifier.html) — Hohpe and Woolf
- [Events: queued event listeners and ShouldQueue](https://laravel.com/docs/12.x/events) — Laravel