Kafka ve olay tabanlı sistemler, doğruluk esas alınarak kurgulanır.
Topic’ler, outbox desenleri, idempotent tüketiciler ve yeniden oynatma — kendi platformlarımızın altındaki olay omurgası, bunu işleten mühendislerce kuruluyor.
- Kafka
- Kafka Connect
- Debezium
- Schema Registry
- Kafka Streams
- Flink
Kurumsal entegrasyonlar çoğu zaman sessizce bozulur.
Bir sistem diğerini çağırır, çağrı zaman aşımına uğrar, taraflardan biri yazmıştır diğeri yazmamıştır ve ay sonu mutabakatına kadar kimse fark etmez. Kafka sorunun biçimini değiştirir: bir üretici bir olguyu kalıcı ve sıralı bir log’a bir kez yazar, her tüketici de onu kendi hızında, en son onayladığı konumdan okur. Yavaş bir sistem artık hızlı olanı bekletmez, bir kesinti kayba değil birikmiş işe dönüşür ve bir hata, veri yeniden girilerek değil log yeniden oynatılarak düzeltilebilir.
Kendi platformlarımızın altındaki teknoloji yığınının bir parçasıdır. Loyalty & Retention’da bir puan hareketi, Sales Performance’ta hesaplanmış bir satış, Order & Supply Management’ta bir yük durumu — her biri, birkaç servisin tepki vermesi gereken türden bir olgudur ve bir olay log’u, raporlamanın bunu kayıt sistemine hiç dokunmadan okumasını sağlar. Müşteriler için kurduğumuz entegrasyon ortamları aynı desenleri kullanır.
Kullanmadığımız durumlar: Yanıtı şimdi gereken bir istek olay değil, API’dir. İki servisi ve tek veritabanı olan bir ekip, kendi kendisiyle konuşmak için dağıtık bir log kurmamalıdır. Basit bir görev kuyruğu için — e-postalar, küçük görseller — RabbitMQ ya da bir bulut kuyruğu, Kafka kümesinden daha iyi bir seçimdir.
Kafka üzerinde geliştirdiğimiz altı şey.
Sistemler arasında olay omurgaları
Sahibi belli topic’ler, üzerinde uzlaşılmış şemalar ve bir registry ile domain olayları; böylece ERP, CRM, faturalama ve aradaki platformlar gecelik dosyalar yerine olgu alışverişi yapar.
Varsayılan olarak outbox deseni
Olay, iş değişikliğiyle aynı PostgreSQL transaction’ı içinde yazılır ve Kafka’ya Debezium ya da bir aktarıcı tarafından iletilir — böylece mesaj kaybettiren çift yazma yarışı ortadan kalkar.
Legacy veri depolarından change data capture
Oracle, SQL Server, MySQL ya da PostgreSQL write-ahead log’ları üzerinde çalışan Debezium, değiştiremediğiniz bir sistemi olay kaynağına dönüştürür — bir legacy yeniden mühendislik programındaki standart ilk adımdır.
Idempotent tüketiciler ve akış işleyicileri
Go, Java ya da Node.js ile yazılmış, açık offset commit’leri, tekilleştirme anahtarları, dead-letter topic’leri ve back-pressure içeren tüketiciler; iş, pencereler üzerinde toplama ise Kafka Streams ya da Flink.
Veri ve yapay zekâ için gerçek zamanlı veri hatları
Dünün toplu işinin geç kaldığı dolandırıcılık, operasyon ve kişiselleştirme senaryoları için veri ambarına ve feature store’lara akan akışlar — sonraki adımdaki modellerin sahibi Veri Mühendisliği.
Kümenin işletilmesi
Yönetilen Kafka (MSK, Confluent Cloud, Event Hubs) ya da Kubernetes üzerinde Strimzi; bölüm stratejisi, saklama süresi, kotalar, izleme ve bir olay anında log’u işe yarar kılan yeniden oynatma araçlarıyla birlikte.
Ne zaman tercih edilmeli.
Birden fazla sistemin aynı olgulara tepki vermesi gerekiyorsa, üretici ile tüketiciler birbirinden bağımsız ölçekleniyor ya da hata veriyorsa, geçmişe ihtiyacınız varsa — yeniden oynatma, denetim, sonradan katılan tüketiciler — ve hacim, mesaj başına aracılığı darboğaza dönüştürecek kadar yüksekse Kafka’yı seçin. Birkaç sistemden fazlasını barındıran entegrasyon ortamlarına, event sourcing ya da CQRS tasarımlarına ve gecelik toplu işi bekleyemeyen operasyonel analitiğe uygundur. Ayrıca “mainframe’deki veriyi ona dokunmadan nasıl dışarı çıkarırız” sorusunun dürüst yanıtıdır.
Etkileşim, senkron yanıt bekleyen bir istekse başka yere bakın — orası REST ya da gRPC’nin işidir. Birkaç arka plan işiniz varsa ve sıralama ya da yeniden oynatma ihtiyacınız yoksa yine başka yere bakın; bir kuyruğu işletmek de anlamak da daha kolaydır. Organizasyonda kümenin, şemaların ve tüketici gecikmesinin sahibi olacak kimse yoksa da dikkatli olun: sahipsiz bir Kafka, verinin izini kaybetmek için çok kalıcı bir yerdir.
Tek transaction, tek olay, çift yazma yok.
begin;
insert into points_ledger (member_id, amount, reason, idempotency)
values ($1, $2, 'flight-earn', $3);
-- the event is part of the same commit as the business fact
insert into outbox (aggregate, aggregate_id, type, payload)
values ('member', $1, 'PointsAwarded', $4);
commit;
-- Debezium reads the outbox from the WAL and publishes to Kafka:
-- topic: loyalty.member.events key: member_id header: idempotency
-- consumers dedupe on the idempotency key and commit offsets after the write
+ create index on outbox (published_at) where published_at is null;Devrettiğimiz hâliyle bir olay omurgası.
Devrettiğimiz olay akışlarında bulunanlar.
- Çift yazma yok. Kaybedilmemesi gereken her olay, üreticiden bir outbox tablosu ya da CDC üzerinden çıkar. Önce veritabanına yazıp ardından ikinci bir adımda Kafka’ya yayın yapan bir servis incelememizden geçemez.
- Idempotent tüketiciler, bir iş tanımlayıcısına anahtarlanır ve offset’ler yalnızca yan etki kalıcı olduktan sonra commit edilir — böylece en az bir kez teslim, tam bir kez sonuç üretir.
- Registry’de tutulan şemalar (Avro ya da Protobuf, ekosistem gerektiriyorsa JSON Schema), CI’da zorunlu kılınan uyumluluk kuralları ve her topic için yazılı bir sahiplik kaydıyla birlikte.
- Bölüm anahtarları kolaylık için değil, sıralama için seçilir. Tek bir üyeye, tek bir yüke ya da tek bir plana ait olaylar aynı bölüme düşer; sıcak anahtarlar canlı ortamda değil, yük testlerinde aranır.
- Yeniden oynatma prosedürü olan dead-letter topic’leri, üstel geri çekilmeli yeniden deneme bütçeleri ve dead-letter hacmiyle tüketici gecikmesi üzerine uyarılar.
- Log boyunca izler. OpenTelemetry bağlamı header’larda taşınır; böylece tek bir istek, API’den üç tüketici üzerinden veri ambarına kadar izlenebilir.
- Saklama ve veri yerleşimi her topic için ayrı kararlaştırılır; kişisel veriler GDPR / KVKK için haritalanır, aktarımda ve durağan hâlde şifrelenir ve her servis kimliği için ayrı ACL’ler tanımlanır — paylaşılan kimlik bilgisi yok.
- Belgelenmiş yeniden oynatma ve felaket prosedürleri — yönettiğimiz akışların, bir zaman aralığını yeniden işlemek ve bir tüketicinin durumunu log’dan yeniden oluşturmak için yazılı ve provası yapılmış bir yolu vardır.
Topic’lerle birlikte genellikle teslim edilenler.
- Repoda registry’nin yanında tutulan bir olay kataloğu — topic’ler, sahipleri, şemalar, anahtarlar, saklama süreleri
- Kod olarak yapılandırılmış outbox ve CDC connector’ları, Debezium ya da aktarıcı kurulumuyla birlikte
- Kendi dilleriniz için, idempotency, dead-letter yönetimi ve izleme yerleşik gelen tüketici şablonları
- Yönetilen küme ya da Strimzi operatörü, kotalar ve ACL’ler için Terraform
- Kod olarak dışa aktarılmış uyarı politikalarıyla gecikme, işlem hacmi ve dead-letter panoları
- Ekibinizle bir game day’de provası yapılan yeniden oynatma ve olay runbook’u
Sık sorulan sorular
Komşu teknoloji yığınları ve onları kullanan hizmetler.
Aynı olgu konusunda birbiriyle çelişen iki sisteminiz mi var?
Hangi sistemler ve ne kadar hacim olduğunu anlatın. Bir Kafka mühendisi okur ve nasıl yaklaşacağımızı yazılı olarak iletir.