Eu realmente preciso da semântica exactly-once do conector Kafka do Flink?

O sink Kafka do Flink pode garantir exactly-once, mas essa garantia está atrelada à conclusão do checkpoint - o que significa que a latência de saída é limitada pelo intervalo de checkpoint, não pela velocidade real do fluxo de dados.

O que exactly-once realmente custa

O sink Kafka do Flink alcança exactly-once através de uma transação de two-phase commit atrelada ao ciclo de checkpoint - ele armazena as escritas e só as confirma no Kafka depois que um checkpoint termina com sucesso. Um consumidor lendo com o nível de isolamento padrão read_committed vê essa saída atrasada pelo intervalo completo de checkpoint, não quase em tempo real.

Quando at-least-once mais escritas idempotentes é igualmente correto, por menos

Se a escrita downstream é naturalmente idempotente - um upsert por um id estável, não um append ou incremento de contador - a entrega at-least-once sem overhead de transação produz exatamente o mesmo estado final que exactly-once, sem o custo de latência do intervalo de checkpoint. Uma entrega duplicada simplesmente sobrescreve a mesma chave com o mesmo valor.

Onde exactly-once é a única resposta correta

Um sink não idempotente - incrementar um contador, adicionar a um log de auditoria onde uma linha duplicada corrompe os totais - não tem um fallback seguro em at-least-once; um registro reproduzido ali é um bug real de correção, não só ruído. Esse é o ponto de decisão real: se o sink é idempotente, não uma preferência geral por garantias mais fortes em todo lugar.