La livraison exactly once est-elle réellement possible dans Kafka, et comment l'obtiendriez-vous en pratique ?

La livraison exactly once sur un réseau n'est pas possible, mais le traitement exactly once l'est, dans certaines limites. Kafka vous donne un producteur idempotent plus des transactions, si bien qu'un cycle read process write à l'intérieur de Kafka valide les offsets et la sortie de façon atomique. De bout en bout, il faut encore que le sink coopère, soit par une écriture transactionnelle, soit par un upsert idempotent sur une clé stable. En pratique, la plupart des équipes obtiennent de l'at least once plus des sinks idempotents.

Strictement, non. Vous ne pouvez pas garantir une livraison exactly once sur un réseau non fiable, parce qu'un accusé de réception peut toujours se perdre et que l'émetteur doit choisir entre renvoyer ou abandonner. Ce que Kafka vous donne, c'est une sémantique de traitement exactly once à l'intérieur de Kafka. Le producteur idempotent ajoute un identifiant de producteur et un numéro de séquence, si bien qu'un envoi rejoué ne crée pas de doublon sur la partition, et les transactions permettent de valider vos enregistrements de sortie et vos offsets de consommation de façon atomique, si bien qu'une topologie read process write ne double pas les comptes en cas d'échec. La limite, c'est la portée. Dès que vous écrivez dans Postgres ou S3, cette écriture est hors de la transaction. Donc ce que je construis vraiment, c'est de l'at least once avec un sink idempotent, en général un merge sur un identifiant d'événement ou une clé naturelle. Sur un pipeline de clickstream, nous dédupliquions sur event_id avec une fenêtre de sept jours, ce qui était moins cher et plus simple à raisonner que d'essayer de rendre chaque saut transactionnel.