Kafka ile Event-Driven Mimari için Claude Promptu

Sen deneyimli bir dağıtık sistemler mimarısın. {sistem_adi} projesinin {kullanim_alani} alanında event-driven (olay güdümlü) bir mimari tasarlamalısın.

## Sistem Parametreleri
- **Sistem Adı:** {sistem_adi}
- **Kullanım Alanı / Domain:** {kullanim_alani}
- **Beklenen Peak Yük:** {beklenen_islem_hacmi} mesaj/saniye
- **Kritiklik Seviyesi:** {kritiklik_seviyesi} (düşük / orta / yüksek / kritik)
- **Geliştirici Ekip Büyüklüğü:** {ekip_buyuklugu} kişi
- **Mevcut Teknoloji Yığını:** {teknoloji_yigini}

## Adım 1 — Domain Event Kataloğu
{kullanim_alani} için tüm domain event'lerini tanımla:
- Her event'i şu formatta adlandır: [Kaynak][Eylem]Event (örn: OrderPlacedEvent, PaymentFailedEvent)
- Event türlerini ayır: Command Events (tetikleyici) / Domain Events (sonuç) / Integration Events (servisler arası)
- Event granülaritesini dengele: ne çok ince (chatty) ne çok kaba (bloated)

## Adım 2 — Mesaj Broker Seçimi
Aşağıdaki broker'ları {beklenen_islem_hacmi} hacmi ve {kritiklik_seviyesi} kritikliği göz önünde bulundurarak karşılaştır ve birini öner:

| Kriter | Apache Kafka | RabbitMQ | AWS SQS/SNS | Redis Streams |
|--------|-------------|----------|-------------|---------------|
| Throughput | Çok yüksek | Yüksek | Orta | Yüksek |
| Gecikme | Düşük | Çok düşük | Orta | Çok düşük |
| Kalıcılık | Log tabanlı | İsteğe bağlı | Yönetilen | İsteğe bağlı |
| Yönetim Karmaşıklığı | Yüksek | Orta | Düşük | Düşük |

**Seçim gerekçeni** şu başlıklara göre yaz: yük kapasitesi, takım operasyonel hazırlığı, maliyet, lock-in riski.

## Adım 3 — Event Schema Tasarımı
Katalogdaki ilk 3 kritik event için tam JSON Schema üret. Her event şu temel yapıyı içermeli:

```json
{
  "eventId": "<uuid-v4>",
  "eventType": "string (örn: OrderPlacedEvent)",
  "version": "string (semver, örn: 1.0.0)",
  "timestamp": "string (ISO 8601)",
  "source": "string (yayıncı servis adı)",
  "correlationId": "<uuid — işlem zinciri takibi>",
  "causationId": "<uuid — tetikleyen event id>",
  "payload": {}
}
```

Schema Registry kullanarak backward/forward uyumluluk stratejisini açıkla.

## Adım 4 — Producer / Consumer Mimarisi
{teknoloji_yigini} için şunları yaz:
1. **Producer Kodu** — event üretme ve serileştirme (hata yönetimi dahil)
2. **Consumer Kodu** — idempotent işleme (duplicate message koruması, veritabanında işlenmiş eventId kontrolü)
3. **Dead Letter Queue (DLQ)** — başarısız mesaj stratejisi: retry politikası (exponential backoff), DLQ'dan manuel/otomatik yeniden işleme akışı
4. **Outbox Pattern** — DB işlemi ve mesaj kuyruğu arasında atomik tutarlılık (2-phase commit yerine)

## Adım 5 — Mimari Diyagram
Mermaid.js syntax ile producer-consumer topolojisini çiz:
- Hangi servis hangi event'i yayımlıyor
- Topic/Queue adları ve partition sayıları
- Consumer group yapısı
- DLQ akışı

## Adım 6 — Gözlemlenebilirlik (Observability)
İzlenecek kritik metrikleri ve alert threshold'larını belirt:
- Consumer lag (kritik eşik: {beklenen_islem_hacmi} × 2 saniye)
- Message error rate (eşik: %1)
- Processing latency p99
- DLQ derinliği

Distributed tracing için correlation ID ile tüm log satırlarını işaretle.

## Çıktı Formatı
Yanıtını şu sırayla ver:

1. **📋 Event Kataloğu** (tablo formatı: Event Adı | Tür | Kaynak Servis | Tüketiciler | SLA)
2. **🏗️ Broker Seçim Kararı** (gerekçeli karşılaştırma + öneri)
3. **📐 Event Schema Örnekleri** (3 kritik event için JSON)
4. **💻 Kod Örnekleri** (Producer, Consumer, DLQ — {teknoloji_yigini} dilinde)
5. **🗺️ Mimari Diyagram** (Mermaid.js flowchart)
6. **📊 Observability Kurulumu** (Prometheus metrikleri ve Grafana alert önerileri)
7. **🚀 Deployment Runbook** (adım adım operasyon rehberi)