Bağlam: 120M kullanıcı, %99.99 SLA, sıfır tolerans

Müşteri 23 yıllık monolitik bir telekom CRM/billing platformuydu. Günde ~480M event, en yoğun saatte 38k RPS, p99 için 250 ms hard limit, abonelik faturalama doğruluğu için ise zero-tolerance. Eski mimaride her şey tek bir Postgres üzerinde XA (iki-fazlı commit) ile çalışıyordu — sorun veritabanı değildi; sorun, dağıtık servisler eklendikçe XA'nın gerçek dünyada çuvallamasıydı.

Ekibimiz 4 ay boyunca platformu adım adım event-driven ve saga + transactional outbox mimarisine taşıdı. Aşağıda kararların matematiği, kırılmaların anatomisi ve geri çekilebilir migrasyon disiplini var.

Neden saga, neden hemen outbox?

İlk içgüdü saga ile başlamak. Ama saga'yı doğrudan eklemek, dağıtık dünyaya en pahalı borçları yazar: kayıp event'ler, çift işlenmiş ödemeler, replay edilemeyen state geçişleri. Bunun için transactional outbox birinci günden gelmek zorunda.

DB'ye yazma ve event yayını aynı transaction'da olur.
Outbox tablosu polling veya CDC ile Kafka'ya akıtılır.
Consumer tarafında transactional inbox ile idempotency garanti edilir.
Aggregate-id partition key — sıralama korunur.

Çekirdek tablo şeması

CREATE TABLE outbox (
  id           UUID PRIMARY KEY,
  aggregate    TEXT NOT NULL,
  type         TEXT NOT NULL,
  payload      JSONB NOT NULL,
  trace_id     TEXT,
  created_at   TIMESTAMPTZ NOT NULL DEFAULT now(),
  published_at TIMESTAMPTZ
);
CREATE INDEX outbox_unpub_idx ON outbox (created_at)
  WHERE published_at IS NULL;

Saga koordinasyonu: orchestration mı, choreography mi?

Choreography ile başladık (her servis kendi event'lerini dinler). Üç ay sonra debug edilemez hale geldi — kim neyi tetikledi belirsizdi. Orchestration'a geçtik: tek bir saga koordinatörü adımları ve telafileri yönetiyor. Koordinatör persisted state machine; restart sonrası saga kayıp olmuyor.

Choreography küçük domain'lerde altın, ama 12+ servis aşıldığında trace cehennemine dönüyor. Orchestration'da koordinatör tek failure point'tir ama observability'i kazanırsın.

Idempotency'i ciddiye almak

At-least-once dünyada idempotency seçenek değil — aksiyom. Anahtarımızı sadece event-id ile değil, iş anlamını taşıyan üçlü ile kuruyoruz:

key = f"{event.type}:{event.aggregate_id}:{event.revision}"
if redis.set(key, "1", nx=True, ex=86400):
    handle(event)

Cutover: shadow → canary → big bang

Hafta 1–2: shadow write — yeni mimariye paralel yazıyoruz, eskiyi okuyoruz, diff metrikleri çıkarıyoruz.
Hafta 3–6: read split — %1, %5, %25, %50 trafiği yeni okuma yoluna canary.
Hafta 7–10: write canary — bölge bazında segmente edilmiş kullanıcı kümeleri.
Hafta 11–12: kalan trafiğin cutover'ı, shadow ve XA'nın kaldırılması.

Observability disiplini

Saga ID'si tüm log'larda, metric'lerde ve trace'lerde. OpenTelemetry collector → Tempo + Loki + Mimir. Her saga için aktif adım, geçen süre, telafi sayısı ve retry sayısı dashboard'da. SLO budget tüketimini paylaştırdık; ekipler kendi servislerinin error budget'ını görüyor.

Sonuçlar (gerçek metrikler)

p99 latency: 240 ms → 78 ms
Event drop rate: 0.04% → 0.0001%
Deploy lead time: 4.2 saat → 11 dakika
Aylık incident sayısı: 18 → 2
Maliyet: aylık %21 düşüş (sadece DB consolidation'dan)
MTTR: 38 dk → 6 dk

Yeniden yapsam ne yapmazdım

İlk 2 hafta saga choreography ile uğraşmazdım — direkt orchestration.
Outbox poller'ı yerine başından beri Debezium kullanırdım.
Idempotency key'i daha geniş tutardım (event-type + aggregate-id + revision + tenant).
Schema Registry'i 1. günden zorunlu yapardım, ileride retroaktif compat acı verir.
Operasyon ekibine chaos drill'i 1. ay başlatırdım.

Yazı bulunamadı

Yazı bulunamadı

Daha fazla yazı

Hizmetler

Mimari & Bulut

Sektör Çözümleri

Ekip & Danışmanlık

Şirket