¿Realmente necesito semántica exactly-once del conector de Kafka de Flink?

El sink de Kafka de Flink puede garantizar exactly-once, pero esa garantía está atada a la finalización del checkpoint - lo que significa que la latencia de salida está acotada por el intervalo de checkpoint, no por la velocidad real del flujo de datos.

Qué cuesta realmente exactly-once

El sink de Kafka de Flink logra exactly-once mediante una transacción de two-phase commit atada al ciclo de checkpoint - almacena las escrituras y solo las confirma a Kafka una vez que un checkpoint termina con éxito. Un consumidor leyendo con el nivel de aislamiento por defecto read_committed ve esa salida retrasada el intervalo completo de checkpoint, no casi en tiempo real.

Cuándo at-least-once más escrituras idempotentes es igual de correcto, por menos

Si la escritura downstream es naturalmente idempotente - un upsert por un id estable, no un append o un incremento de contador - la entrega at-least-once sin overhead de transacción produce exactamente el mismo estado final que exactly-once, sin el costo de latencia del intervalo de checkpoint. Una entrega duplicada simplemente sobrescribe la misma clave con el mismo valor.

Dónde exactly-once es la única respuesta correcta

Un sink no idempotente - incrementar un contador, añadir a un log de auditoría donde una fila duplicada corrompe los totales - no tiene un respaldo seguro en at-least-once; un registro reproducido ahí es un bug real de corrección, no solo ruido. Ese es el punto de decisión real: si el sink es idempotente, no una preferencia general por garantías más fuertes en todas partes.