Ist Exactly-once-Delivery in Kafka tatsächlich möglich, und wie würdest du es in der Praxis erreichen?

Exactly-once-Delivery über ein Netzwerk ist nicht möglich, Exactly-once-Processing schon, in Grenzen. Kafka gibt dir einen idempotenten Producer plus Transaktionen, sodass ein Read-Process-Write-Zyklus innerhalb von Kafka Offsets und Output atomar committet. End-to-end muss der Sink trotzdem mitspielen, entweder über einen transaktionalen Write oder ein idempotentes Upsert auf einem stabilen Key. In der Praxis landen die meisten Teams bei At-least-once plus idempotenten Sinks.

Streng genommen nein. Du kannst Exactly-once-Delivery über ein unzuverlässiges Netzwerk nicht garantieren, weil ein Acknowledgment immer verloren gehen kann und der Sender zwischen erneut senden und verwerfen wählen muss. Was Kafka dir gibt, ist Exactly-once-Processing innerhalb von Kafka. Der idempotente Producer hängt eine Producer-ID und eine Sequenznummer an, sodass ein wiederholter Send kein Duplikat auf der Partition erzeugt, und Transaktionen erlauben dir, Output-Records und Consumer-Offsets atomar zu committen, sodass eine Read-Process-Write-Topologie bei Fehlern nicht doppelt zählt. Die Grenze ist die Reichweite. Sobald du nach Postgres oder S3 schreibst, liegt dieser Write außerhalb der Transaktion. Was ich also tatsächlich baue, ist At-least-once-Delivery mit idempotentem Sink, meist ein Merge auf einer Event-ID oder einem natürlichen Schlüssel. In einer Clickstream-Pipeline haben wir auf event_id mit einem Fenster von sieben Tagen dedupliziert, was billiger und leichter zu durchdenken war, als jeden Hop transaktional machen zu wollen.