Los eventos de facturación duplicados son una característica estructural de los sistemas distribuidos, no un caso excepcional. La lógica de reintentos, la inestabilidad de la red, los reinicios de las aplicaciones y las garantías de reenvío de las colas de mensajes dan lugar a situaciones en las que un mismo evento facturable se envía a tu sistema de facturación más de una vez. Si tu plataforma de facturación no elimina correctamente los duplicados, estos generan sobrecostes y los clientes los detectan antes que tú.
El objetivo de la deduplicación de eventos en la facturación es facturar cada evento facturable único exactamente una vez. Ni dos veces (sobrecoste), ni cero veces (pérdida de ingresos), ni una vez para la mayoría de los eventos y ocasionalmente dos veces para otros (sobrecostes sistemáticos pero intermitentes, que son los más difíciles de detectar). Exactamente una vez. Siempre. Sea cual sea el volumen.
La mayoría de las empresas descubren que tienen un problema de deduplicación de la peor manera posible: un cliente se da cuenta de que su factura es considerablemente más alta de lo esperado y presenta una reclamación. Los cobros excesivos suelen haberse ido acumulando durante semanas o meses, ya que una tasa de duplicación del 0,1 % no genera una reclamación por cada evento duplicado. Solo se recibe una reclamación cuando el efecto acumulativo finalmente se hace visible en una factura. Detectar y corregir retroactivamente la facturación duplicada sistemática, con facturas ya emitidas, es mucho más difícil que prevenirla. La primera señal casi siempre se encuentra en los registros de eventos sin procesar, no en los informes de facturación. La mayoría de los equipos no revisan esos registros hasta después de que se haya producido la reclamación.
De dónde proceden los duplicados
Lógica de reintento
La causa más habitual. Cuando un generador de eventos envía un evento de uso a tu sistema de facturación y no recibe una confirmación dentro de un plazo de espera, vuelve a intentarlo. Si la primera solicitud se había realizado correctamente, pero la respuesta se retrasó o se perdió, ahora tienes dos copias del mismo evento en el proceso. Con volúmenes de transacciones bajos, esto supone una molestia ocasional. Con 10 millones de eventos al día, una tasa de reintentos del 0,5 % supone 50 000 posibles duplicados diarios.
Garantías de entrega «al menos una vez»
La mayoría de las colas de mensajes y plataformas de streaming (Kafka, SQS, Pub/Sub) funcionan, por defecto, con una semántica de entrega «al menos una vez». Garantizan que se entregue cada mensaje, pero no que se entregue exactamente una vez. Se trata de una elección de diseño deliberada: la entrega «exactamente una vez» es considerablemente más compleja y costosa de lograr a nivel de infraestructura. La consecuencia práctica es que tu aplicación recibe mensajes duplicados, y eres responsable de gestionarlos correctamente.
Si tu canal de captación de eventos se encuentra situado después de cualquiera de estos sistemas, estarás recibiendo datos duplicados. La cuestión es si tu sistema de facturación los gestiona.
Reinicios de la aplicación y recuperación ante fallos
Cuando un servicio que genera eventos de facturación se reinicia tras un fallo, puede volver a enviar eventos recientes como parte de su proceso de recuperación. Si no mantiene un registro de los eventos que ya ha enviado correctamente, los volverá a enviar. Esto es especialmente habitual en los flujos de trabajo de IoT y telemetría, donde el firmware de los dispositivos implementa una lógica de recuperación sencilla del tipo «enviar todo lo que hay en el búfer al restablecerse la conexión», sin tener en cuenta la deduplicación.
Errores en la capa de integración
Las capas de integración desarrolladas internamente entre tu producto y tu sistema de facturación son un terreno propicio para la generación de eventos duplicados. Un error en un gestor de webhooks, una tarea cron que se ejecuta dos veces en determinadas condiciones, un problema de sincronización entre dos fuentes de datos que registran la misma métrica de uso. Cualquiera de estos casos puede generar flujos duplicados sistemáticos que persisten hasta que alguien detecta las anomalías en las facturas.
Cómo funciona la deduplicación de eventos en la facturación: el patrón de clave idempotente
El enfoque estándar para la deduplicación de eventos en la facturación es el patrón de clave de idempotencia. Cada evento de uso lleva un identificador único (la clave de idempotencia) que genera el productor del evento y que permanece inalterable en todos los reintentos. La clave de idempotencia de un evento determinado es la misma, independientemente de si el evento se envía una, dos o diez veces.
El sistema de facturación mantiene un registro de las claves de idempotencia procesadas. Cuando llega un evento, el sistema compara la clave con este registro. Si la clave ya se ha registrado anteriormente, el evento se considera un duplicado y se descarta. Si la clave es nueva, el evento se procesa y la clave se añade al registro.
Este enfoque funciona de forma fiable siempre que se cumplan tres condiciones:
- Cada evento tiene una clave de idempotencia estable y única. El sistema de facturación no puede generarla; la clave que se crea al recibir el evento es diferente cada vez, lo que implica que los reintentos no se detectan. El productor debe generarla antes del primer envío y mantenerla estable durante los reintentos.
- La clave se deriva del contenido del evento, no de los metadatos del envío. Cualquier dato que genere el sistema receptor (una marca de tiempo del servidor, un identificador secuencial) variará entre el envío original y el reintento. Básala en los atributos del propio evento: el identificador del cliente, la marca de tiempo del evento, el tipo de métrica y la cantidad.
- El registro de idempotencia es duradero y tiene una larga vida útil. Un registro en memoria no se conserva tras un reinicio. Cualquier entrada enviada antes del reinicio se convierte en un posible duplicado la próxima vez que llegue. El registro debe almacenarse en un soporte duradero, y el periodo de retrospectiva debe abarcar al menos varios días, o incluso más en el caso de los flujos de trabajo en los que los eventos pueden llegar con un retraso considerable.
El problema de la deduplicación excesiva
Es menos habitual (aunque igual de perjudicial) cometer un error en la deduplicación de eventos en la facturación al ser demasiado estricto. Si tu lógica de deduplicación descarta eventos que en realidad no son duplicados (porque comparten algunas características con un evento anterior, pero son realmente distintos), estás omitiendo un uso real y facturando de menos.
Esto ocurre con mayor frecuencia cuando los equipos implementan la deduplicación heurística en lugar de la deduplicación basada en claves. Por ejemplo: «si recibimos dos eventos con el mismo ID de cliente, tipo de métrica y cantidad en un intervalo de cinco minutos, se considerará el segundo como un duplicado». El problema es que, a un cliente que realiza la misma acción dos veces en cinco minutos (dos llamadas a la API del mismo tamaño, dos subidas de datos idénticas), se descarta silenciosamente su segundo evento.
La deduplicación basada en claves idempotentes evita esto por completo. La clave es estable y única. Si dos eventos distintos comparten el mismo ID de cliente, tipo de métrica y cantidad, pero tienen claves diferentes, se trata de eventos distintos y ambos se procesan. La clave es el único criterio de decisión.
Consideraciones sobre la escala
El enfoque del registro de idempotencia es sencillo desde el punto de vista conceptual, pero plantea verdaderas limitaciones técnicas a gran escala. Con 10 millones de eventos al día, el registro acumula 300 millones de entradas al mes. El tiempo de búsqueda de claves, el almacenamiento del registro y las políticas de conservación del mismo se convierten en decisiones de diseño nada triviales.
En el caso de una plataforma de facturación, se trata de un problema ya resuelto, pero cada proveedor lo aborda de forma diferente, con distintas características de rendimiento y distintos plazos de retención. Pregunta específicamente:
- ¿Cuál es el plazo de conservación del registro de idempotencia? Si se produce un nuevo intento 30 días después del evento original, ¿se identifica correctamente como un duplicado?
- ¿Cuál es el tiempo de búsqueda en una consulta de clave en momentos de máximo volumen de eventos? ¿Aumenta la deduplicación la latencia en el proceso de ingesta?
- ¿El registro de idempotencia se mantiene intacto tras los reinicios del sistema y los fallos de la infraestructura?
Cómo detectar eventos duplicados que ya estás generando
Si no estás seguro de si tu sistema está generando registros duplicados, aquí tienes una forma práctica de comprobarlo:
Extrae una muestra de eventos de facturación de un solo día. Para cada evento, comprueba si el mismo ID de cliente, tipo de métrica, cantidad y marca de tiempo aproximada aparecen más de una vez en el registro. Una tasa de duplicación no insignificante (incluso del 0,1 %) es una señal de que tus productores de eventos están generando reintentos que no se están detectando.
Si tu sistema de facturación no facilita los registros de eventos sin procesar. Si lo único que puedes ver es la cantidad agregada medida, no podrás realizar esta comprobación. Eso ya es en sí mismo una señal. Deberías poder examinar el flujo de eventos sin procesar en el que se basa cualquier factura.
Preguntas frecuentes
¿Qué es la deduplicación de eventos en la facturación?
La deduplicación de eventos es el proceso de identificar y descartar los eventos de uso que ya se han procesado, de modo que los envíos duplicados no den lugar a un sobrefacturación. Dado que la mayoría de los sistemas de entrega de eventos utilizan la semántica «al menos una vez» (que garantiza la entrega, pero no la entrega «exactamente una vez»), es habitual que los sistemas de facturación reciban eventos duplicados. La deduplicación es el mecanismo que convierte la entrega «al menos una vez» en una facturación «exactamente una vez».
¿Qué provoca que se produzcan eventos de facturación duplicados?
Tres causas principales: las garantías de entrega «al menos una vez» de colas de mensajes como Kafka o SQS, que pueden entregar cada mensaje más de una vez; los reinicios de aplicaciones y la recuperación ante fallos, en los que los servicios reproducen los eventos almacenados en el búfer al volver a conectarse sin comprobar si ya se habían entregado; y los errores en la capa de integración de los conectores personalizados, en particular los gestores de webhooks o las tareas programadas, que pueden activarse más de una vez en determinadas condiciones.
¿Qué es una clave de idempotencia en el procesamiento de eventos?
Una clave de idempotencia es un identificador único y estable que el generador del evento asocia a cada evento de uso. La clave debe generarse antes del primer intento de envío y permanecer inalterada durante los reintentos. El sistema de facturación mantiene un registro de todas las claves que ha detectado; cuando llega un evento, se comprueba la clave: si ya se ha detectado anteriormente, el evento se descarta. La clave debe proceder del generador, no del sistema receptor: una clave generada en el momento de la recepción es siempre una clave nueva, lo que significa que los reintentos nunca se reconocen como duplicados.
¿Qué es la deduplicación excesiva y por qué es peligrosa?
La «sobrededuplicación» se produce cuando la lógica de deduplicación descarta eventos que, en realidad, no son duplicados, ya que, aunque comparten características con un evento anterior, representan un uso genuinamente distinto. Por ejemplo, si la lógica descarta cualquier segundo evento con el mismo ID de cliente, tipo de métrica y cantidad en un plazo de cinco minutos, se descarta de forma silenciosa la segunda llamada a la API idéntica de un cliente. La sobrededuplicación provoca una facturación inferior a la real y no genera quejas de los clientes, por lo que puede persistir indefinidamente. La deduplicación basada en claves idempotentes evita esto por completo: la clave es el único árbitro, no el contenido.
¿Cómo se comprueba si el sistema de facturación está generando cobros duplicados?
Extrae una muestra de eventos de facturación de un día representativo. Para cada evento, comprueba si el mismo ID de cliente, tipo de métrica, cantidad y marca de tiempo aproximada aparecen más de una vez en el registro. Una tasa de duplicación superior al 0,1 % indica que los generadores de eventos están produciendo reintentos no gestionados. Si tu sistema de facturación no expone el flujo de eventos sin procesar —sino solo cantidades agregadas—, no podrás realizar esta comprobación. Esa limitación en sí misma es una señal: un sistema de facturación que no puede mostrarte su registro de eventos sin procesar hace imposible diagnosticar el origen de cualquier discrepancia en la facturación.
Para consultar la guía completa para profesionales sobre medición y clasificación, visita billingplatform.com/metering-and-rating.
Véase también: ¿Qué provoca la pérdida de ingresos y cómo evitarla ? | ¿Qué es la mediación en la facturación? | Cómo funcionan los motores de tarificación: una guía técnica | Fijación de precios basada en fórmulas: cuando las consultas por niveles no son suficientes | Cómo evaluar una plataforma de medición y tarificación
