Diseño de sistemas

1. Capacidad y retención

Suponga que las lecturas contienen una identidad de medidor autenticada, interval_start en UTC, medición de caudal y versión del payload. Los intervalos se alinean a límites de 15 minutos. La identidad lógica es (meter_id, interval_start), independiente de los intentos de carga.

Ingesta en estado estable:

• Lecturas por medidor al día: 24 × 60 / 15 = 96.
• Lecturas de la flota por día: 1.200.000 × 96 = 115.200.000.
• Lecturas promedio por segundo: 1.200.000 / 900 = 1.333,33.
• Volumen bruto diario: 115.200.000 × 200 = 23.040.000.000 bytes = 23,04 GB.
• Almacenamiento bruto durante 400 días: 23,04 × 400 = 9.216 GB.
• Con tres réplicas: 9.216 × 3 = 27.648 GB = 27,648 TB.

Estas son estimaciones solo del payload, usando unidades decimales. Los índices, el encuadre de registros, las cargas duplicadas temporales, los registros operativos y la sobrecarga del sistema de archivos requieren capacidad adicional. Aplique el ciclo de vida de 400 días a las lecturas brutas canónicas, no a cada copia de reintento. Mantenga los libros de facturación por separado según la política de retención financiera de la empresa de suministro.

2. Dimensionamiento de la reconexión e ingesta

La tormenta desconecta 1.200.000 × 30% = 360.000 medidores. Cada uno almacena en búfer 6 × 4 = 24 lecturas, lo que da 360.000 × 24 = 8.640.000 lecturas acumuladas.

Con cargas distribuidas a lo largo de 600 segundos:

• Tasa de acumulado: 8.640.000 / 600 = 14.400 lecturas/segundo.
• Tasa concurrente en vivo: 1.333,33 lecturas/segundo.
• Pico sostenido de lecturas únicas: 15.733,33 lecturas/segundo.
• Rendimiento correspondiente en la red: 15.733,33 × 200 = 3,1467 MB/segundo.

Este es el pico sostenido de diez minutos especificado, no un límite para lotes instantáneos ni para el tráfico de reintentos. Distribuya las cargas del acumulado a lo largo de la ventana de reconexión y aplique equidad por medidor para que las lecturas en vivo no queden sin recursos.

Utilice pasarelas autenticadas sin estado, un registro duradero replicado particionado por medidor, grupos de consumidores independientes, almacenamiento canónico, una proyección para el panel y un procesador de fugas. Aprovisione pasarelas para al menos 60.000 intentos de carga/segundo y consumidores posteriores para 30.000 lecturas únicas/segundo. Estos valores proporcionan margen para reintentos; no asumen que los reintentos tengan un máximo matemáticamente acotado.

Confirme cada lectura solo después de la persistencia duradera con quórum, con réplicas en dominios de fallo distintos. Las confirmaciones parciales de lote identifican con precisión qué registros son duraderos. Los registros no confirmados siguen siendo elegibles para reintento. Las pasarelas confirman muy por debajo de 30 segundos bajo la carga indicada, evitando la amplificación de reintentos durante la operación normal.

El acumulado ocupa por sí mismo 8.640.000 × 200 = 1,728 GB, o 5,184 GB replicados. Reserve al menos 100 GB de capacidad replicada del registro, con margen adicional para el encuadre. Nunca desaloje registros confirmados no procesados: extienda la retención o desborde a almacenamiento duradero si los consumidores se retrasan.

Las colas absorben lotes e interrupciones de los consumidores. El autoescalado, la contrapresión y la admisión priorizada protegen la durabilidad. El acumulado de seis horas deja 42 horas antes de la sobrescritura del medidor; la capacidad de ingesta diseñada lo drena dentro de la ventana de carga de diez minutos. Ningún sistema puede recuperar lecturas ya sobrescritas, ni garantizar la entrega durante una interrupción que supere el límite de búfer del medidor.

3. Corrección de facturación y del panel

La base de datos de facturación aplica un conteo exactamente una vez, no el transporte. Su libro de intervalos tiene una restricción de unicidad sobre (meter_id, interval_start).

Para cada lectura consumida, una transacción de base de datos inserta el intervalo y actualiza el acumulador del periodo de facturación solo si la inserción tiene éxito. Un duplicado se convierte en una operación nula. El consumidor confirma su desplazamiento en el registro solo después de que la transacción se confirme; por tanto, los fallos provocan una repetición segura. Los payloads en conflicto para una misma identidad se ponen en cuarentena en lugar de reemplazar silenciosamente un valor ya facturado. Las correcciones aprobadas usan un libro de ajustes explícito.

La facturación se cierra solo después de la conciliación de completitud. Las lecturas faltantes siguen siendo excepciones que requieren la política de la empresa de suministro, nunca consumo inventado. Esto garantiza que cada intervalo válido recibido se cuente una sola vez a pesar de los reintentos.

El panel realiza de forma independiente un upsert sobre la misma clave. Mida la latencia de llegada a visibilidad y dimensione su ruta normal para el objetivo de percentil 99 de cinco minutos. Durante las tormentas, escale los consumidores y drene el acumulado en un plazo de 60 minutos. Muestre la hora de medición y la frescura de los datos para que las lecturas históricas tardías no aparezcan como actuales.

4. Detección de fugas en tiempo de evento

El procesamiento de fugas usa interval_start, nunca el orden de llegada. Almacene las lecturas deduplicadas en un mapa ordenado de intervalos por medidor. Una alerta candidata requiere 96 inicios de intervalo adyacentes, separados exactamente por 15 minutos, cada uno con caudal distinto de cero.

Las lecturas tardías pueden conectar fragmentos previamente separados, por lo que alertar inmediatamente por cada fragmento observado podría generar varias notificaciones para una única racha final. En su lugar, emita notificaciones solo desde un prefijo de tiempo de evento finalizado.

Añada un protocolo de completitud de carga por medidor: un medidor informa una frontera solo después de que cada intervalo anterior haya sido confirmado de forma duradera o declarado explícitamente como no disponible por haber expirado. El servidor avanza la frontera de procesamiento solo después de que esas lecturas confirmadas hayan llegado al almacenamiento canónico. Los reintentos pendientes y los lotes en vuelo impiden el avance prematuro. Persista estas fronteras y las declaraciones de huecos.

No asuma que "48 horas de antigüedad" por sí solo demuestra completitud: la transmisión y el procesamiento pueden añadir retrasos. Los medidores desconectados no pueden avanzar su frontera, por lo que sus alertas esperan a la conciliación. No se especificó ningún requisito de latencia para las alertas.

Un intervalo faltante es desconocido, no cero y no distinto de cero. Impide que cualquier ventana de 96 intervalos que lo cruce sea elegible. Mientras esté sin resolver, también impide la finalización. Una vez declarado explícitamente como no disponible, rompe la racha consecutiva verificada sin afirmar que el agua dejó de fluir.

Procese los intervalos finalizados en orden cronológico, manteniendo el recuento consecutivo de valores distintos de cero y un indicador de alerta emitida. Al llegar al recuento de 96, cree de forma transaccional una única entrada en la bandeja de salida de notificaciones, identificada por medidor e inicio de racha verificada. Los intervalos distintos de cero posteriores conservan el indicador. Un intervalo finalizado con cero o no disponible termina esa racha verificada. Los identificadores de notificación duraderos y un endpoint de entrega idempotente impiden que una repetición cree otra alerta lógica.

5. Exactamente tres compensaciones

1. Elegido: confirmación con registro duradero primero. Descartado: confirmar antes de persistir. Las escrituras con quórum añaden latencia y coste de infraestructura, pero los reintentos siguen siendo seguros y las lecturas confirmadas sobreviven a fallos de las pasarelas.

2. Elegido: libro de intervalos transaccional para facturación. Descartado: confiar en la entrega exactamente una vez a nivel de transporte. La unicidad de la base de datos y las actualizaciones atómicas del acumulador cuestan capacidad de escritura, pero protegen directamente el invariante financiero de conteo ante repeticiones y caídas.

3. Elegido: alertas de fugas finalizadas en tiempo de evento. Descartado: alertas inmediatas en orden de llegada con correcciones posteriores. El seguimiento de completitud retrasa las notificaciones, especialmente tras una desconexión, pero evita que datos tardíos en búfer fusionen fragmentos notificados de forma independiente en una sola racha.

Diseño y capacidad

Utilice un registro de ingesta duradero y replicado entre las pasarelas orientadas a medidores y los servicios posteriores. Las pasarelas autentican los medidores, validan la marca temporal del intervalo y la carga útil, y publican las lecturas con clave (meter_id, interval_start). Particione el registro por ID de medidor para que los registros de un mismo medidor se mantengan ordenados, distribuyendo a la vez los medidores entre las particiones. Confirme una carga solo después de que el registro se haya replicado de forma duradera en las réplicas requeridas. Si se pierde la confirmación, el medidor puede reintentar; el sistema acepta el duplicado en lugar de arriesgar la pérdida de datos.

La tasa en estado estable es:

• 1.200.000 medidores ÷ 900 segundos por intervalo = 1.333,3 lecturas/segundo.
• 1.200.000 × 96 intervalos/día = 115.200.000 lecturas/día.
• 115.200.000 × 200 bytes = 23.040.000.000 bytes/día = 23,04 GB/día.
• Durante 400 días: 23,04 GB × 400 = 9.216 GB = 9,216 TB de lecturas sin procesar. Con tres réplicas: 9,216 TB × 3 = 27,648 TB.

Estas cifras usan el tamaño de registro especificado en la red y unidades decimales; excluyen índices, sobrecarga del formato de almacenamiento y margen operativo. Almacene el historial completo de lecturas sin procesar en un archivo replicado y particionado por tiempo, y conserve el registro de ingesta el tiempo suficiente para cubrir la recuperación normal de los consumidores, en lugar de usarlo como archivo de 400 días.

Para la tormenta indicada, 30% × 1.200.000 = 360.000 medidores se ven afectados. Seis horas contienen 6 × 4 = 24 intervalos, por lo que los medidores que se reconectan suben 360.000 × 24 = 8.640.000 lecturas almacenadas en búfer. Distribuidas en 10 minutos, son 8.640.000 ÷ 600 = 14.400 lecturas/segundo. Sumando el tráfico en vivo de todos los medidores, 1.333,3 lecturas/segundo, se obtiene un pico nominal de aproximadamente 15.733 lecturas/segundo. La carga de llegada de 10 minutos es de unos 9,44 millones × 200 bytes = 1,888 GB, incluidas aproximadamente 800.000 lecturas en vivo.

Dimensione la capacidad de las pasarelas y de escritura en el registro para al menos 32.000 lecturas/segundo sostenidas, aproximadamente el doble del pico calculado, y reserve capacidad de cola para al menos toda la ventana de llegada de 9,44 millones de registros, con espacio adicional para reintentos y retraso de procesamiento. El registro replicado absorbe la ráfaga mientras los consumidores se ponen al día; después, consumidores escalables de forma independiente escriben el archivo, el almacén de facturación, la vista del panel y el estado de alertas. Esta capacidad absorbe la ráfaga descrita sin descartar lecturas aceptadas. El límite de sobrescritura de 48 horas del medidor es una limitación ascendente: las lecturas sobrescritas antes de la reconexión no pueden recuperarse en el backend.

Corrección y servicio

La facturación utiliza una tabla canónica de lecturas con una restricción de unicidad aplicada por la base de datos sobre (meter_id, interval_start). Su destino realiza una operación de inserción o conflicto: la primera copia inserta la lectura, y los reintentos o cargas repetidas con la misma clave no crean otro intervalo facturable. La facturación agrega únicamente esta tabla canónica. El destino confirma la lectura y su progreso en el consumidor del registro de forma transaccional, o usa escrituras seguras ante repetición, de modo que un fallo y una reproducción no puedan contar dos veces. Un duplicado con valores en conflicto debe marcarse para investigación en lugar de contarse silenciosamente como otro intervalo.

Un consumidor independiente mantiene una vista materializada orientada al cliente. Realiza upserts con la misma clave de intervalo y actualiza la última lectura mostrada según el tiempo del intervalo, no según el orden de llegada. Supervise la latencia de extremo a extremo desde la llegada hasta la vista y escale consumidores y particiones para cumplir el objetivo en operación normal de que el 99% sea visible en cinco minutos. Durante la ráfaga especificada, la vista puede retrasarse hasta 60 minutos; el registro duradero y el archivo permanecen intactos mientras se pone al día. Puede mostrarse a los clientes información de actualidad para que una vista retrasada no se confunda con una lectura actual.

La detección de fugas es un cálculo de tiempo de evento agrupado por medidor y ordenado por interval_start. Deduplique cada intervalo antes de evaluarlo, y conserve los resultados de los intervalos para que una lectura tardía pueda actualizar el estado y provocar el recálculo de la serie de intervalos afectada. No decida que un intervalo falta solo porque llegó antes un intervalo posterior. Avance una marca de completitud solo después de que se hayan procesado todos los registros del registro recibidos hasta el tiempo de ingesta correspondiente, y sitúela al menos 48 horas por detrás del tiempo de ingesta, con margen operativo adicional para el retraso de las colas. Esto tiene en cuenta el máximo período de almacenamiento en búfer del medidor.

Un intervalo faltante se trata como si no mostrara flujo distinto de cero: una vez que queda por detrás de esa marca de completitud y no existe ninguna lectura, rompe una serie consecutiva. Antes de ese momento está sin resolver, no es un cero. Cuando 96 intervalos consecutivos finalizados muestren todos flujo distinto de cero, emita una sola alerta para esa racha. Persista una identidad de alerta basada en el medidor y la racha, y use una bandeja de salida de notificaciones idempotente para que la reproducción no envíe otra alerta para la misma racha. Esperar la completitud puede retrasar una alerta hasta el horizonte de tardanza, pero evita que una lectura tardía y desordenada produzca un resultado incorrecto.

Exactamente tres compensaciones

1. Elegido: registro replicado antes de los consumidores. Descartado: escrituras síncronas desde las pasarelas a todos los destinos. El registro añade infraestructura y algo de latencia, pero amortigua las ráfagas de reconexión y aísla la ingesta de servicios lentos de facturación o del panel.
2. Elegido: vistas materializadas del panel actualizadas de forma asíncrona. Descartado: distribución síncrona hacia el panel durante la ingesta. Las actualizaciones eventuales cumplen los objetivos indicados de cinco minutos en operación normal y 60 minutos durante la ráfaga, mientras mantienen rápidas las consultas de los clientes; la distribución síncrona acoplaría la aceptación de los medidores a la disponibilidad del panel y a la carga de la ráfaga.
3. Elegido: alertas de fugas basadas en marcas de agua y conscientes de datos tardíos. Descartado: alertas inmediatas basadas en el orden de llegada. Esperar la ventana de tardanza acotada cuesta velocidad de alerta, pero permite rachas correctas basadas en intervalos y un tratamiento explícito de los datos faltantes.

1. Estimaciones de capacidad

Tasa en régimen estable

• 1.200.000 medidores ÷ 900 s por intervalo = 1.333 lecturas/s
• 1.333 × 200 B ≈ 267 KB/s

Volumen bruto por día

• Lecturas por día: 1.200.000 × 96 intervalos = 115,2 M
• Bytes por día: 115,2 M × 200 B = 23,04 × 10^9 B = 23,04 GB/día

Almacenamiento bruto para la retención

• Una copia: 23,04 GB × 400 días = 9.216 GB = 9,216 TB
• Con 3 réplicas: 9,216 TB × 3 = 27,65 TB

Los índices y la sobrecarga de compactación se suman a esta cifra. La compresión columnar probablemente la reducirá mucho.

2. Ráfaga de reconexión

Tasa máxima

• Medidores fuera de línea: 30% × 1,2 M = 360.000
• Lecturas almacenadas en búfer por medidor: 6 h × 4 intervalos/h = 24
• Backlog total: 360.000 × 24 = 8,64 M lecturas
• Todos los medidores se reconectan en 600 s, distribuidos uniformemente: 8,64 M ÷ 600 = 14.400 lecturas/s
• Se suma el tráfico en vivo: 14.400 + 1.333 = 15.733 lecturas/s. Eso equivale a unas 11,8 veces el régimen estable, o aproximadamente 3,15 MB/s.
• Si las confirmaciones se ralentizan, los reintentos podrían duplicar esta cifra, por lo que dimensiono para unas 32.000 lecturas/s.

Cómo absorbe el diseño la ráfaga

1. Pasarelas sin estado (MQTT/HTTPS detrás de un balanceador de carga) verifican las credenciales de los medidores y el esquema de la carga útil. Se dimensionan para 32 k/s más capacidad de reserva N+1.
2. Registro duradero (Kafka, factor de replicación 3, acks=all, particionado por meter_id). La pasarela envía al medidor su confirmación solo después de que la escritura en el registro esté confirmada. Por tanto, toda lectura confirmada es duradera, y una lectura no confirmada la reintenta el medidor. En ambos casos no se pierde nada. Unos pocos MB/s son trivialles para Kafka, así que las escrituras siguen siendo rápidas y las confirmaciones llegan muy por debajo del tiempo de espera de 30 s, lo que mantiene los reintentos poco frecuentes.
3. Dos temas. La pasarela envía las lecturas con interval_start en los últimos 30 minutos a live, y todo lo anterior a backfill. Los consumidores vacían primero live, de modo que el objetivo de 5 minutos del panel se cumple para los datos en vivo incluso durante una tormenta.
4. Los consumidores posteriores absorben el backlog. No necesitan seguir el ritmo del pico. A 5.000 lecturas/s, el backlog de 8,64 M se vacía en unos 29 minutos, dentro del límite relajado de 60 minutos del panel. La retención de Kafka es de 7 días, así que incluso una caída del consumidor no pierde datos.
5. Variabilidad en el lado del medidor. El firmware añade un retardo aleatorio al reconectar y al reintentar, lo que suaviza aún más la ráfaga.

3. Facturación exactamente una vez

La base de datos del libro de facturación garantiza el conteo exactamente una vez. Utiliza la clave primaria (meter_id, interval_start).

• El consumidor de facturación escribe con INSERT … ON CONFLICT (meter_id, interval_start) DO NOTHING.
• Las subidas reintentadas, las repeticiones de la pasarela y el reprocesamiento del consumidor tras una caída simplemente chocan con el conflicto y no cambian nada.
• Los offsets de Kafka se confirman solo después de que la escritura en la base de datos tenga éxito. Esto produce entrega al menos una vez en un destino idempotente, lo que en la práctica equivale a exactamente una vez.
• Si llega un duplicado con un valor distinto, se conserva el primer valor almacenado y el conflicto pasa a una cola de conciliación. Nunca se suma.
• Los totales de facturación se calculan únicamente a partir de esta tabla deduplicada.
• El almacén del panel (una base de datos de series temporales) usa la misma clave como upsert, de modo que sus gráficos también están libres de duplicados.

4. Alertas de fuga en tiempo de evento

Un procesador de flujos con estado (por ejemplo Flink), agrupado por meter_id, lee ambos temas y trabaja en tiempo de evento (interval_start), no en tiempo de llegada.

Estado por medidor

• Un mapa de bits sobre los últimos 296 intervalos (48 h más 24 h de historial más margen). Cada ranura es distinta de cero, cero o desconocida.
• Las rachas actuales, cada una identificada por su primer intervalo.
• Un indicador para cada racha que registra si ya ha generado una alerta.

Reglas

• Una lectura tardía rellena su ranura, esté donde esté. El orden de llegada no importa, y un duplicado no tiene efecto.
• Una alerta se dispara solo cuando 96 ranuras consecutivas están todas presentes y son todas distintas de cero. Como cada ranura debe estar rellena con datos confirmados, una llegada posterior nunca puede invalidar una alerta ya generada.
• Intervalo ausente. Mientras una ranura tenga menos de 48 h de antigüedad (más 1 h de gracia), es desconocida. No extiende ni rompe una racha, y la alerta simplemente espera. Una vez que haya pasado interval_start + 49 h, la lectura ya no puede llegar, así que la ranura se finaliza como ausente, lo que rompe la racha. Nunca se genera una alerta sobre datos no verificados.
• Una alerta por racha. El registro de alerta se identifica por (meter_id, streak_start) en una tabla de alertas con restricción de unicidad, de modo que un evento reprocesado no puede enviar una segunda alerta. Una racha termina con una lectura cero o con un hueco finalizado. Si una lectura tardía rellena un hueco y une dos rachas, la racha fusionada conserva el streak_start más antiguo y hereda el indicador de "ya alertada", por lo que sigue recibiendo solo una alerta.
• El estado se guarda en un punto de control en almacenamiento duradero. Tras un reinicio, el procesador se reproduce desde los offsets confirmados y reconstruye el mismo estado.

5. Compensaciones

1. Cuándo confirmar una lectura

   • Elegido: confirmar tras la escritura replicada en el registro. Esto garantiza que ninguna lectura se pierda y cuesta unos pocos milisegundos por confirmación.
   • Descartado: confirmar al recibir, desde memoria. Es más rápido, pero una caída de la pasarela eliminaría en silencio lecturas que el medidor ya borró de su búfer.

2. Cómo eliminar duplicados

   • Elegido: escrituras idempotentes con una clave única en el libro de facturación. Es sencillo, fácil de comprobar y sobrevive a cualquier repetición desde cualquier origen.
   • Descartado: transacciones exactamente una vez de extremo a extremo en Kafka. No detectan duplicados creados antes de Kafka, como un medidor que reintenta tras perder una confirmación. Además añaden coste de coordinación y son difíciles de operar.

3. Cómo tratar un intervalo ausente en la detección de fugas

   • Elegido: un hueco finalizado rompe la racha. Así no hay falsas alertas basadas en datos supuestos, y cada alerta puede respaldarse ante el cliente. El coste es que una fuga real con un corte de conectividad de 48 horas puede detectarse con retraso.
   • Descartado: tratar los huecos como continuación de la racha, o rellenarlos a partir de lecturas vecinas. Esto detecta más fugas, pero genera alertas basadas en lecturas que nunca existieron y vuelve poco clara la regla de "una alerta por racha".

Resumen

• Capacidad: 1.333 lecturas/s en régimen estable, 23,04 GB/día, 27,65 TB almacenados con 3 réplicas.
• Ráfaga: pico de 15.733 lecturas/s, absorbido por un registro duradero que confirma solo tras una escritura verificada, y por prioridad para los datos en vivo.
• Facturación: el conteo exactamente una vez se garantiza mediante la clave única del libro de facturación.
• Alertas de fuga: calculadas en tiempo de evento, nunca generadas sobre datos no verificados, y limitadas a una por racha.

1. Estimaciones de capacidad

Estado estable

• Intervalos por día: 24 h × 4 = 96.
• Lecturas por segundo: 1,200,000 / 900 s = ≈1,333 lecturas/s. Esto equivale a unos 267 KB/s en la red.
• Lecturas por día: 1,200,000 × 96 = 115.2 M.
• Volumen bruto por día: 115.2 M × 200 B = 23.04 GB, es decir, ≈23 GB/día.
• Retención: 23.04 GB × 400 días = 9,216 GB ≈ 9.2 TB de una copia.
• Con 3 réplicas: 9.216 TB × 3 = ≈27.6 TB (27,648 GB).
• Esto excluye índices y compresión. Añadiría alrededor de un 30% de margen, lo que da una cifra aprovisionada de unos 36 TB.

2. Ráfaga por reconexión

• Medidores afectados: 30% × 1.2 M = 360,000.
• Intervalos almacenados en búfer por medidor: 6 h × 4 = 24.
• Backlog: 360,000 × 24 = 8.64 M lecturas, que son 1.73 GB.
• Ventana de subida: 10 min = 600 s, distribuidos uniformemente, así que la tasa del backlog es 8.64 M / 600 = 14,400/s.
• El tráfico en vivo continúa a 1,333/s.
• Pico = 14,400 + 1,333 ≈ 15,733 lecturas/s, unas 11.8× el estado estable, o unos 3.1 MB/s.

Los reintentos se suman a esto. Si los acuses de recibo se retrasan más de 30 s, los medidores reenvían. Por ello dimensiono la ruta de ingesta para 2× el pico, unos 32,000/s. En la práctica, eso significa 8 nodos de ingesta sin estado a unos 5,000/s cada uno, con N+2 de reserva.

Cómo no se pierde nada

1. La pasarela de ingesta valida una lectura y la añade a un registro duradero particionado, como Kafka. Usa acks=all, factor de replicación 3 y min.insync.replicas=2. Envía al medidor su acuse de recibo solo después de que la escritura tenga éxito.
2. El registro tiene 48 particiones indexadas por meter_id y conserva 7 días de datos. La ráfaga es de unos 3 MB/s, así que es trivial para el registro. Los consumidores pueden retrasarse minutos u horas sin pérdida.
3. Si la pasarela o el registro están sobrecargados, devuelven 503 o no envían acuse. El medidor conserva la lectura y reintenta. Su búfer de 48 horas cubre una interrupción de 6 horas más la recuperación, lo que deja unas 42 horas de margen. Por tanto, la contrapresión nunca descarta datos.
4. Los consumidores posteriores (escritor de facturación, proyector del panel y procesador de fugas) tienen grupos de consumidores separados. Confirman los offsets solo después de que sus escrituras tengan éxito, de modo que un fallo provoca repetición, no pérdida.
5. Los consumidores están dimensionados para unos 30,000/s. El backlog de 8.64 M se vacía entonces en unos 5 minutos, muy dentro del presupuesto relajado de 60 minutos del panel. En funcionamiento normal, el retraso se mantiene en segundos, lo que cumple el objetivo de 5 minutos para el 99% de las lecturas.

3. Facturación exactamente una vez

La entrega es al menos una vez en todas partes: reintentos de medidores, reintentos de la pasarela y repeticiones del registro. El efecto exactamente una vez lo garantiza un componente: el almacén de lecturas, un almacén SQL replicado (3 réplicas, particionado por meter_id). Tiene una clave primaria (meter_id, interval_start).

• El escritor de facturación ejecuta INSERT … ON CONFLICT DO NOTHING. Un duplicado no tiene efecto, ya provenga de un reintento del medidor, de una repetición o de un reinicio del consumidor.
• Los totales de facturación se calculan consultando esta tabla. Nunca se guardan como contadores de flujo que podrían incrementarse dos veces.
• interval_start lo establece el medidor y está alineado a la cuadrícula de 15 minutos. La pasarela rechaza los valores desalineados y los pone en cuarentena.
• Si llega una clave duplicada con una carga distinta, gana la primera escritura. El conflicto se registra en una tabla de discrepancias para revisión, de modo que la facturación nunca se altera en silencio.
• Los consumidores posteriores actúan solo sobre las filas que la inserción indica como recién creadas. Por tanto, el panel y el procesador de fugas también están deduplicados.

Este almacén es también el almacén bruto. Sus 27.6 TB son la cifra replicada calculada arriba.

4. Alertas de fugas con datos tardíos y desordenados

La regla se evalúa según interval_start, así que el procesador usa tiempo de evento y no mantiene ventanas por tiempo de llegada. Es un trabajo de flujo con estado indexado por meter_id que consume solo las lecturas recién insertadas.

Estado por medidor (unos 70 bytes):

• Un anillo de 2 bits por intervalo, que cubre los últimos 288 intervalos (72 horas). Los tres valores son desconocido, cero y no cero.
• alerted_range = [start, end] para la última racha alertada.

En cada lectura en el intervalo t:

1. Establecer la ranura de t.
2. Si no es cero, recorrer hacia la izquierda y hacia la derecha desde t para encontrar la serie contigua máxima de intervalos no cero que contiene t.
3. Si la longitud de la serie es ≥ 96 y no se solapa con alerted_range, emitir una alerta. Después, establecer alerted_range como la serie.
4. Si la serie se solapa con alerted_range, ampliar alerted_range y no emitir nada.

Como el estado depende solo del conjunto de lecturas y no de su orden, un lote que llega en orden inverso da el mismo resultado que una llegada en orden. Una lectura tardía que rellena un hueco puede unir dos series más cortas en una de 96, y entonces se dispara la alerta. Una lectura cero termina la racha. La siguiente serie que cumpla la condición es una racha nueva y puede volver a alertar.

Las alertas se escriben en una tabla de salida (outbox) en la misma transacción que alerted_range, y una clave única (meter_id, streak_start) lo respalda. Por tanto, las repeticiones y los reinicios no pueden enviar una segunda alerta.

Intervalos ausentes. Un intervalo ausente es desconocido. No es cero ni no cero, y nunca se interpola. Rompe la contigüidad, así que no se lanza ninguna alerta a través de un hueco. La racha se reevalúa automáticamente si la lectura que falta llega más tarde, lo que puede ocurrir hasta 48 horas después del intervalo. Pasadas 48 horas, se pierde de forma permanente y la racha queda rota. Esto favorece que no haya falsas alarmas, a costa de una posible alerta retrasada o perdida tras una interrupción larga. Si resulta que las alertas perdidas son peores que las falsas, se puede añadir un aviso separado de "hueco de datos".

El estado de más de 72 horas se desaloja. Las lecturas más antiguas que el límite de 48 horas no pueden llegar legítimamente, así que se registran y se ignoran.

5. Compromisos

1. Cuándo confirmar al medidor.

• Elegido: confirmar después de la escritura duradera en el registro.
• Descartado: confirmar después de la escritura en el almacén SQL.
• Motivo: la escritura en el registro es un añadido rápido que no se ve afectado por la carga de la base de datos. Así, una ráfaga no puede alargar la latencia de confirmación más allá de 30 s ni desencadenar tormentas de reintentos.
• Coste: los datos no son consultables todavía en el momento de la confirmación. Es aceptable porque la facturación tolera el retraso y el panel permite 60 minutos durante una ráfaga.

2. Dónde deduplicar.

• Elegido: una restricción de clave primaria en la base de datos con inserción idempotente.
• Descartado: deduplicación a nivel de flujo, es decir, transacciones de Kafka o una caché de "vistos" en memoria o basada en filtro de Bloom.
• Motivo: las transacciones de Kafka cubren solo el salto del registro, no los reintentos del medidor que crean mensajes nuevos. Una caché es limitada y puede perderse al reiniciar, y un filtro de Bloom tiene falsos positivos, lo que descartaría una lectura facturable.
• Coste: cada duplicado cuesta una inserción conflictiva barata. Con 2× el pico, esto está muy dentro de la capacidad del almacén.

3. Cómo evaluar las fugas.

• Elegido: un mapa de bits por medidor dirigido por eventos, evaluado en cada nueva lectura.
• Descartado: un escaneo periódico por lotes o ventanas cerradas por marcas de agua.
• Motivo: el mapa de bits es independiente del orden y tolera un retraso de 48 horas sin ningún retardo de marca de agua, así que las alertas se disparan en cuanto llega el último intervalo que faltaba. Las ventanas necesitarían una marca de agua de 48 horas y retrasarían cada alerta, o emitirían resultados incorrectos que requerirían corrección posterior.
• Coste: unos 85 MB de estado indexado (1.2 M × unos 70 B) y una recuperación cuidadosa del estado desde los puntos de control.

Arquitectura Regional de Ingesta de Contadores de Agua Inteligentes

1. Estimaciones de Capacidad y Aritmética

Lecturas por Segundo en Estado Estable

• Flota de contadores: $1,200,000$ contadores.
• Intervalo: Cada 15 minutos ($15 \times 60 = 900$ segundos).
• Cálculos:
  $$\text{Rendimiento en Estado Estable} = \frac{1,200,000\text{ lecturas}}{900\text{ segundos}} = 1,333.33\text{ lecturas/segundo}$$

Volumen de Datos Brutos por Día

• Lecturas por contador por día: $\frac{24\text{ horas} \times 60\text{ minutos}}{15\text{ minutos}} = 96\text{ lecturas/día}$.
• Total de lecturas diarias: $1,200,000 \times 96 = 115,200,000\text{ lecturas/día}$.
• Tamaño de la carga útil: $200\text{ bytes/lectura}$ en la red.
• Cálculos (usando unidades decimales donde $1\text{ GB} = 10^9\text{ bytes}$):
  $$\text{Volumen de Ingesta Diario} = 115,200,000 \times 200\text{ bytes} = 23,040,000,000\text{ bytes} = 23.04\text{ GB/día}$$

Almacenamiento Bruto para Retención de 400 Días (con 3 Réplicas)

• Almacenamiento de 400 días con una sola copia:
  $$400\text{ días} \times 23.04\text{ GB/día} = 9,216\text{ GB} = 9.216\text{ TB}$$
• Almacenamiento con replicación triple:
  $$9,216\text{ GB} \times 3 = 27,648\text{ GB} = 27.648\text{ TB}$$

2. Dimensionamiento y Absorción de Ráfagas por Reconexión

Cálculos del Pico de Ráfaga

• Contadores afectados: $30% \text{ de } 1,200,000 = 360,000\text{ contadores}$.
• Duración de la interrupción: 6 horas = $6 \times 4 = 24\text{ intervalos}$ acumulados por contador.
• Total de lecturas almacenadas en búfer: $360,000 \times 24 = 8,640,000\text{ lecturas}$.
• Ventana de reconexión: 10 minutos = $600\text{ segundos}$ (distribuidos uniformemente).
• Tasa de llegada de la ráfaga desde el backlog:
  $$\text{Tasa de Ráfaga} = \frac{8,640,000\text{ lecturas}}{600\text{ segundos}} = 14,400\text{ lecturas/segundo}$$
• Tráfico concurrente de estado estable en vivo: $1,333.33\text{ lecturas/segundo}$.
• Rendimiento máximo combinado:
  $$\text{Tasa Pico} = 14,400 + 1,333.33 = 15,733.33\text{ lecturas/segundo} \approx 15,734\text{ lecturas/segundo}$$
• Ancho de banda de ingreso máximo:
  $$15,734\text{ lecturas/s} \times 200\text{ bytes} = 3,146,800\text{ bytes/s} \approx 3.15\text{ MB/s (25.2 Mbps)}$$

Estrategia de Absorción

1. Terminación en el Borde y ACK Rápido: Una flota de API Gateways sin estado y escalados horizontalmente da entrada al endpoint de ingesta. Dado que los contadores reintentan tras 30 segundos sin ACK, el gateway verifica la estructura del lote y añade inmediatamente la carga útil a un registro de confirmación distribuido (Apache Kafka) antes de confirmar HTTP 202/200 en menos de 50 milisegundos. Esto elimina los timeouts de cliente no confirmados y los reintentos en cascada.
2. Desacoplamiento mediante Cola: Kafka actúa como un amortiguador de choques duradero. Las particiones se distribuyen estrictamente por hash de meter_id (usando 64 particiones para manejar cómodamente hasta $50,000\text{ msgs/seg}$). Aunque el procesamiento de los consumidores aguas abajo se ralentiza durante la ráfaga, la ruta de ingreso persiste el flujo de datos de 3.15 MB/s directamente en disco sin aplicar contrapresión a los gateways del borde.
3. Limitación de Consumo para el Dashboard del Cliente: Los workers de proyección del dashboard del cliente limitan el consumo de ingesta, cumpliendo fácilmente el SLO de ráfaga relajado de 60 minutos y permitiendo que los procesadores de facturación y de flujos de alertas críticas dispongan de capacidad de consumo dedicada.

3. Ingesta de Facturación con Exactly-Once

Los reintentos de red producen inevitablemente mensajes duplicados con el mismo (meter_id, interval_start). El diseño garantiza el conteo exactly-once en la Capa de Carga de Almacenamiento de Facturación (Pipeline de Ingesta de Facturación) mediante una combinación de upserts idempotentes y restricciones de clave primaria relacional.

Mecanismo

• Clave Natural: La clave primaria del libro mayor de staging de facturación es (meter_id, interval_start).
• Frontera de Deduplicación: Un cargador de lotes transaccional consume eventos de Kafka y los escribe en una base de datos de libro mayor de facturación inmutable de solo anexado, usando semántica de upsert determinista (INSERT ... ON CONFLICT (meter_id, interval_start) DO NOTHING).
• Idempotencia en Dos Fases:
  1. Antes del staging, un procesador de flujo con estado (por ejemplo, Apache Flink) utiliza una tabla de estado respaldada por RocksDB que mantiene un filtro de deduplicación deslizante de 48 horas (coincidiendo con el búfer máximo de 48 horas del contador). Los reintentos de red duplicados que ocurran dentro de esta ventana se descartan de inmediato.
  2. Cualquier reintento que eluda lo anterior o que se recargue tras reinicios de workers choca con la restricción del índice único de la base de datos sobre (meter_id, interval_start). Las consultas de agregación de facturación suman únicamente sobre este libro mayor deduplicado, haciendo matemáticamente imposible el sobreconteo.

4. Motor de Alertas de Fugas con Lecturas Fuera de Orden / Faltantes

Lógica de Detección

Una fuga continua se define como 96 intervalos consecutivos de 15 minutos (24 horas continuas) de flujo distinto de cero, evaluados estrictamente por interval_start.

Pipeline de Procesamiento de Flujos

1. Marcas de Agua y Retraso Permitido: Una topología de streaming (Apache Flink) mantiene un estado con clave por contador que rastrea intervalos contiguos. Dado que los contadores pueden almacenar en búfer hasta 48 horas, el job de streaming configura un umbral de retraso permitido de 48 horas. Las lecturas tardías se redirigen al estado con clave del contador en lugar de descartarse.
2. Bitset de Contigüidad / Árbol de Rangos: Cada contador mantiene una estructura de estado de intervalos que contiene los intervalos evaluados más recientes ordenados por interval_start. Cuando llega una ráfaga fuera de orden, los intervalos ocupan sus ranuras correspondientes en la línea temporal cronológica.
3. Tratamiento de Intervalos Faltantes:
   • Si un intervalo falta debido a pérdida de paquetes, desfase de reloj o por superar el límite de sobrescritura del búfer de 48 horas del contador, se trata como un flujo contiguo desconocido/interrumpido.
   • Dado que la especificación exige 96 intervalos consecutivos de flujo confirmado distinto de cero, un intervalo faltante reinicia la racha activa a cero. El motor nunca asume flujo ni flujo cero para datos faltantes.
4. Garantía de Alerta Única:
   • La máquina de estados rastrea streak_count y un indicador booleano alert_emitted_for_current_streak.
   • Cuando streak_count alcanza 96, el motor evalúa si alert_emitted_for_current_streak es false. Si lo es, emite la alerta de fuga y establece el indicador en true.
   • Los intervalos consecutivos distintos de cero posteriores incrementan streak_count pero suprimen nuevas alertas. Solo cuando lectura cero (o intervalo faltante) rompe la racha se limpia streak_count y se restablece alert_emitted_for_current_streak a false.

5. Compensaciones Arquitectónicas

Compensación 1: Momento de la Confirmación de Ingesta

• Opción Elegida: Confirmar la recepción en cuanto las lecturas brutas se confirman en la cola de mensajes distribuida (Kafka).
• Opción Descartada: Confirmar la recepción solo después de que las escrituras se confirmen en la base de datos histórica de largo plazo y en las tablas de facturación.
• Justificación: Un ACK completo de extremo a extremo durante una tormenta de reconexión de 15,734 rps arriesga alcanzar cuellos de botella de E/S de la base de datos. Si las respuestas superan el timeout de 30 segundos del contador, los contadores reintentan, multiplicando exponencialmente la carga de ingreso. El ACK a nivel de cola garantiza la persistencia en milisegundos y apaga los reintentos de inmediato.

Compensación 2: Arquitectura de Cómputo para la Detección de Fugas

• Opción Elegida: Procesador de streaming con tiempo de evento y estado (Apache Flink con backend de estado RocksDB).
• Opción Descartada: Consultas SQL por lotes periódicas sobre tablas de la base de datos analítica (por ejemplo, ejecutadas cada 15 minutos).
• Justificación: Los escaneos SQL por lotes sobre millones de contadores con llegadas tardías fuera de orden requieren consultar ventanas deslizantes masivas de varios días sobre miles de millones de filas para reconstruir huecos y rachas. El motor de streaming con estado evalúa el estado deslizante de forma incremental al llegar, manteniendo la latencia mínima y eliminando los escaneos repetidos de tablas.

Compensación 3: Almacenamiento de Datos del Dashboard del Cliente

• Opción Elegida: Almacén de series temporales/NoSQL preagregado y optimizado para lectura (por ejemplo, Apache Cassandra / ScyllaDB).
• Opción Descartada: Consultas bajo demanda directamente sobre la base de datos relacional normalizada de facturación.
• Justificación: Las consultas del dashboard presentan alta concurrencia de lectura y requisitos de consistencia laxos (permitiendo hasta 60 minutos de retraso durante las ráfagas). Desacoplar las lecturas del dashboard del almacén de facturación protege las transacciones financieras de los picos de consultas de clientes y permite el escalado horizontal con más de 23 GB por día.

Arquitectura de ingesta de contadores inteligentes de agua

1. Estimaciones de capacidad y aritmética

Para construir un back-end robusto para 1,2 millones de contadores inteligentes, comenzamos con un dimensionamiento determinista de capacidad y almacenamiento.

• Lecturas por segundo en estado estable: Cada contador transmite una lectura cada 15 minutos (900 segundos). Para 1.200.000 contadores, la tasa media de ingesta es $1.200.000 / 900 = 1.333,33$ lecturas por segundo.
• Volumen de datos brutos por día: A 1.333,33 lecturas por segundo, el número total de lecturas diarias es $1.333,33 \times 86.400 = 115.200.000$ lecturas/día. Con cada lectura de 200 bytes en la red, el volumen de datos brutos diario es $115.200.000 \times 200 \text{ bytes} = 23.040.000.000 \text{ bytes/día}$ (o 23,04 GB/día).
• Almacenamiento bruto para todo el período de retención incluyendo replicación: Los datos deben conservarse durante 400 días con 3 réplicas. El cálculo de almacenamiento total es $23,04 \text{ GB/día} \times 400 \text{ días} \times 3 \text{ réplicas} = 27.648 \text{ GB}$ (o 27,64 TB).

2. Ruta de ingesta y dimensionamiento de la ráfaga por reconexión

Cuando ocurre una tormenta importante, el 30% de los contadores ($360.000$ contadores) pierde conectividad durante 6 horas. Durante 6 horas, cada contador desconectado almacena en búfer $6 \times 4 = 24$ lecturas. Cuando se restablece la conectividad, los 360.000 contadores suben sus 24 lecturas almacenadas repartidas uniformemente en una ventana de 10 minutos (600 segundos).

• Tasa de subida almacenada en búfer: La tasa de lecturas históricas durante la ráfaga es $(360.000 \text{ contadores} \times 24 \text{ lecturas}) / 600 \text{ segundos} = 8.640.000 / 600 = 14.400$ lecturas por segundo.
• Tasa de datos en vivo concurrente: Simultáneamente, los 1.200.000 contadores continúan enviando sus lecturas normales en vivo a $1.333,33$ lecturas por segundo.
• Tasa máxima de ingesta: La tasa máxima total es $14.400 + 1.333,33 = 15.733,33$ lecturas por segundo (aproximadamente 15,7k rps).

Para absorber esta oleada sin descartar ninguna lectura, la capa de ingesta utiliza un broker de mensajes distribuido y escalable horizontalmente (como Apache Kafka) particionado en 64 particiones. Una flota de API Gateway, colocada detrás de un balanceador de carga, termina TLS, realiza una validación rápida del esquema y escribe directamente en el broker de mensajes. Dado que las particiones de Kafka desacoplan la ingesta del procesamiento posterior, la oleada se almacena de forma segura en búfer en registros de confirmación respaldados por disco. Los workers consumidores escalan dinámicamente según el retraso del consumidor (consumer lag), gestionando la oleada temporal sin pérdida de datos.

3. Idempotencia y facturación exactamente una vez

Los contadores reintentan las subidas si no reciben una confirmación en 30 segundos, lo que significa que los duplicados llegarán con toda seguridad. Para garantizar que la facturación cuente cada (meter_id, interval_start) exactamente una vez, aplicamos idempotencia dentro del Procesador de flujo de facturación.

Cada carga útil de lectura entrante contiene una clave natural compuesta: meter_id e interval_start. El procesador de flujo de facturación consume lecturas del broker de mensajes y utiliza una operación de upsert atómica contra un almacén de datos columnar distribuido o un almacén de estado de deduplicación (como RocksDB integrado en Apache Flink).

Cuando llega una lectura, el procesador comprueba si ya se ha procesado y facturado un registro para (meter_id, interval_start). Si la clave existe, la carga útil duplicada se descarta de forma segura o se marca como duplicada, garantizando cero doble conteo. Si la clave no existe, la tabla de facturación se actualiza y se envía una confirmación de vuelta al broker de ingesta.

4. Datos tardíos y alertas de fuga

La detección de fugas requiere identificar cuándo un contador muestra un flujo distinto de cero en cada uno de 96 intervalos consecutivos de 15 minutos (que cubren un período completo de 24 horas), evaluado estrictamente por interval_start en lugar del tiempo de llegada. Para garantizar que las alertas de fuga sigan siendo correctas cuando las lecturas almacenadas en búfer llegan tarde y fuera de orden, empleamos procesamiento de flujos en tiempo de evento con marcas de agua (watermarking).

• Gestión de datos tardíos: El procesador de flujos mantiene ventanas de estado indexadas por meter_id. Dado que los contadores pueden almacenar datos en búfer durante hasta 48 horas, las ventanas de procesamiento de flujos se configuran con un umbral de retraso permitido de 48 horas. Esto garantiza que, cuando lleguen subidas por lotes retrasadas o tras una reconexión, se inserten retroactivamente en sus intervalos cronológicos correctos de 15 minutos según sus marcas de tiempo interval_start.
• Intervalos ausentes: Si un intervalo de 15 minutos falta por completo en el flujo y su ventana de retraso de 48 horas se cierra sin recibir datos, dicho intervalo se trata explícitamente como flujo cero (o como datos ausentes que rompen una racha contigua). Una lectura ausente rompe la racha de flujo distinto de cero, reiniciando el contador consecutivo de 96 intervalos para ese contador.
• Disparo de alertas: Una vez que un contador acumula 96 intervalos contiguos distintos de cero, el sistema dispara exactamente una alerta por racha. Las lecturas distintas de cero posteriores en la misma ejecución continua no generan alertas duplicadas, gracias a indicadores de deduplicación con estado almacenados junto al contador de la racha activa.

5. Compensaciones arquitectónicas

Para finalizar el diseño del sistema, evaluamos tres decisiones arquitectónicas críticas:

1. Protocolo de ingesta: opción elegida (HTTP/REST con JSON sobre TLS) frente a opción descartada (MQTT / sockets TCP personalizados). Aunque los sockets TCP personalizados o MQTT ofrecen una menor sobrecarga de carga útil, HTTP/REST con JSON está universalmente soportado por los módulos de pasarela celular e IoT, simplifica la depuración, se integra de forma nativa con los cortafuegos de gestión de API existentes y acomoda fácilmente el requisito de tamaño de 200 bytes en la red sin pilas de protocolos de firmware especializadas.
2. Paradigma de almacenamiento: opción elegida (archivos Parquet en almacenamiento de objetos para datos fríos + log distribuido para datos calientes) frente a opción descartada (clúster SQL relacional distribuido tradicional). Mantener 400 días de datos históricos de series temporales más 3 réplicas en un clúster de base de datos relacional tradicional introduce costes de infraestructura prohibitivos y límites complejos de sharding horizontal. Al volcar las lecturas brutas compactadas en archivos Parquet columnares en almacenamiento de objetos (por ejemplo, AWS S3), consultados mediante motores de consulta sin servidor, logramos una retención a largo plazo rentable mientras la ruta operativa activa se mantiene rápida.
3. Consistencia del panel: opción elegida (consistencia eventual mediante proyecciones de modelo de lectura) frente a opción descartada (consultas síncronas de lectura directa a la base de datos). Para garantizar que las consultas del panel sigan siendo ágiles durante las masivas ráfagas de reconexión (15,7k rps), elegimos proyecciones asíncronas de modelo de lectura que actualizan los paneles de los clientes en un plazo de 5 minutos en condiciones de carga normales (y se relajan hasta 60 minutos durante tormentas). Descartamos las consultas síncronas de lectura directa porque bloquear o consultar el almacén transaccional principal durante ráfagas de ingesta máxima provocaría tiempos de espera en cascada, agotamiento del pool de conexiones de la base de datos y un posible fallo de la ingesta.