Kafka'da exactly-once processing tam olarak nasıl çalışır?

Question

Accepted Answer

**Exactly-once semantics (EOS)**, her mesajın tam olarak bir kez işlenmesini — veri kaybı yok, tekrar yok — hatta hatalar ve yeniden denemeler olsa bile sağlar. Kafka bunu **idempotent producers** ve **transactions** aracılığıyla gerçekleştirir, ancak bu karmaşık ve ek yüke sahiptir.

## Zorluk

```text
Exactly-once is HARD in distributed systems (failures, retries, duplicates are inevitable):
  → producer retries → duplicate messages; consumer reprocessing → duplicate effects
  → naive at-least-once → duplicates; at-most-once → loss
→ exactly-once requires careful mechanisms to avoid BOTH loss AND duplicates.
```

## Kafka exactly-once'i nasıl başarır

```text
1. IDEMPOTENT PRODUCER (enable.idempotence=true):
  → the producer dedupes retries (sequence numbers per partition) → producing the same
    message twice (due to a retry) results in ONE write (no duplicates from retries)
2. TRANSACTIONS:
  → group writes (and consumer offset commits) into an ATOMIC transaction → all succeed
    or all roll back
  → enables "consume-process-produce" atomically: read, process, write results + commit
    offsets together → exactly-once across the pipeline (within Kafka)
→ Kafka Streams uses these for end-to-end exactly-once processing
```

## Kapsam ve trade-off'lar

```text
⚠️ Exactly-once is WITHIN KAFKA (consume-process-produce to Kafka):
  → EXTERNAL side effects (e.g. writing to an external DB, calling an API) aren't covered →
    still need idempotency for those
⚠️ Has OVERHEAD (transactions, coordination) → performance cost
→ often AT-LEAST-ONCE + idempotent processing is simpler and sufficient → use exactly-once
  when truly needed (duplicates unacceptable and idempotency hard)
```

## Neden önemli

Kafka'da exactly-once processing'in nasıl çalıştığını anlamak, **exactly-once'in önemli ama yaygın olarak yanlış anlaşılan bir garanti** olduğu için kıdemli düzey bilgidir, bu nedenle nasıl çalıştığını ve sınırlarını anlamak daha derin Kafka bilgisini yansıtır.

Exactly-once semantics'i (hatalar rağmen veri kaybı yok, tekrar yok) arzu edilir ancak dağıtık sistemlerde genuinely zordur; burada yeniden denemeler ve tekrarlar kaçınılmazdır, ve Kafka'nın bunu nasıl başardığını (ve sınırlarını) anlamak sofistike bilgidir.

**Zorluğu** anlamak — kaçınılmaz hatalar ve yeniden denemeler rağmen exactly-once'in hem kaybı hem de tekrarı önlemesi gerektiği — neden zor olduğunu çerçevelendirir.

**Kafka'nın bunu nasıl başardığını** anlamak — **idempotent producers** (sequence numbers aracılığıyla yeniden denemeleri deduplicating, böylece yeniden deneme kaynaklı tekrarlar tek bir yazma ile sonuçlanır) ve **transactions** (yazmaları ve offset commit'lerini atomik olarak gruplandırarak, "consume-process-produce" pattern'ini etkinleştirer; burada okuma, işleme ve yazma sonuçları artı offset commit'leme atomik olarak gerçekleşir — Kafka içinde end-to-end exactly-once), Kafka Streams bunu end-to-end exactly-once için kullanarak — mekanizmaları açıklar.

Kritik olarak, **kapsam ve trade-off'ları** anlamak daha derin, doğru anlayışı yansıtır: exactly-once, **Kafka içinde** (consume-process-produce to Kafka)dir, bu nedenle **harici side effects** (harici veritabanına yazma, API çağırma) **kapsamında değildir** ve yine de kendi idempotency'lerini gerektirir — yaygın olarak yanlış anlaşılan bir sınırlama.

Ve exactly-once'in **overhead'i** vardır (transactions, coordination), bu nedenle **at-least-once artı idempotent processing çoğu zaman daha basit ve yeterlidir**, exactly-once tekrarlar gerçekten kabul edilemez ve idempotency zor olduğunda rezerve edilir.

Bu dengeli anlayış — exactly-once'in nasıl çalıştığını, gerçek kapsamını (Kafka içinde, harici değil), ve gerçekten ne zaman gerekli olduğunu bilmek — doğru, sofistike Kafka bilgisini yansıtır ve exactly-once'in tüm tekrar endişelerini çözdüğü yaygın yanılgısını önler.

Exactly-once önemli ama yaygın olarak yanlış anlaşılan bir garanti olduğundan, ve Kafka'nın bunu nasıl başardığını (idempotent producers, transactions), gerçek kapsamını (Kafka içinde, harici side effects değil), ve ne zaman gerçekten gerekli olduğunu anlamak daha derin, doğru Kafka bilgisini yansıttığından, Kafka'da exactly-once processing'in nasıl çalıştığını anlamak kıdemli düzey bilgidir — bu arzu edilen ama karmaşık garantiyi, mekanizmalarını (idempotent producers, transactions), ve çok önemlisi sınırlarını (yalnızca Kafka içinde, overhead ile) doğru şekilde anlamak için önemlidir, Kafka güvenilirliği ile çalışan kıdemli mühendislerden beklenen sofistike, doğru anlayışı yansıtır.