🛠️ Gerçek Hayatta Kafka — Hands-On

Gerçek Hayatta Kafka — Hands-On: Bu bölüm sizi gerçek bir e-ticaret sipariş işleme pipeline'ından geçirir — tıpkı kargo şirketlerinin her koliye taktığı takip barkoduyla düşünün:

Bu bölüm sizi gerçek bir e-ticaret sipariş işleme pipeline'ından geçirir — tıpkı kargo şirketlerinin her koliye taktığı takip barkoduyla düşünün: barkod tarandığında "depo girişi", "araçta", "teslim edildi" gibi her durum değişikliği merkezi bir sisteme event olarak yazılır ve ilgili tüm birimler (müşteri, şube, muhasebe) bu event'lere bağımsız olarak tepki verir. Neden her servise doğrudan HTTP çağrısı yapmak yerine event'ler kullanalım diye sorulabilir: çünkü sipariş servisi ödeme, bildirim ve analitik servislerinin adreslerini bilmek zorunda kalır ve herhangi biri çöktüğünde sipariş de başarısız olur — oysa Kafka'da sipariş servisi yalnızca topic'e yazar, geri kalanı bağımsız olarak devam eder. Java açısından bu pattern JMS Publisher-Subscriber'a benzer, fark şudur: mesaj bir kez okunsa bile log'da kalır ve her yeni consumer group geçmişi başından okuyabilir — monolitik `OrderService.processOrder()` metoduna kıyasla her servis bağımsız olarak ölçeklenir. QA açısından bu mimariyi anlamak zorunludur: sipariş onaylandı ama bildirim servisi e-posta göndermedi mi, stok düştü ama analitik güncellenemedi mi — bu hataların kökeni Kafka topic lag'ıdır ve `kafka-consumer-groups --describe` komutu gerçek zamanlı tespit sağlar.

Senaryo: E-Ticaret Sipariş İşleme Pipeline'ı

Sipariş event'i 4 servis üzerinden Kafka ile akar

Adım 1: Docker Compose ile Kafka başlat

Üç Farklı Topic Neden Farklı Partition Sayısıyla Oluşturulur?

"orders" ve "payments" topic'leri 3…

"orders" ve "payments" topic'leri 3 partition'la oluşturulur — bu, yüksek hacimli akışların paralel işlenmesine izin verir (3 consumer aynı anda çalışabilir).

"orders-failed" ise SADECE 1 partition'la…

"orders-failed" ise SADECE 1 partition'la oluşturulur — hata akışı düşük hacimlidir, paralellik yerine SIRALI işleme (tüm hatalar tek bir yerde, kronolojik) daha değerlidir.

Her --create komutu --replication-factor 1…

Her `--create` komutu `--replication-factor 1` kullanır — bu sadece LOKAL geliştirme içindir; production'da bu değer en az 3 olmalıdır (tek broker kaybında veri kaybı olmasın diye).

--list komutu üç topic'in de gerçekten…

`--list` komutu üç topic'in de gerçekten oluştuğunu doğrular — bir sonraki adımdaki produce/consume simülasyonu bu doğrulamaya bağımlıdır.

Adım 2: Pipeline'ı manuel olarak simüle et