Design de sistemas

1. Capacidade e retenção

Considere que as leituras contêm uma identidade de medidor autenticada, interval_start em UTC, medição de vazão e versão do payload. Os intervalos são alinhados a limites de 15 minutos. A identidade lógica é (meter_id, interval_start), independente das tentativas de upload.

Ingestão em regime estacionário:

• Leituras por medidor por dia: 24 × 60 / 15 = 96.
• Leituras da frota por dia: 1.200.000 × 96 = 115.200.000.
• Média de leituras por segundo: 1.200.000 / 900 = 1.333,33.
• Volume bruto diário: 115.200.000 × 200 = 23.040.000.000 bytes = 23,04 GB.
• Armazenamento bruto por 400 dias: 23,04 × 400 = 9.216 GB.
• Com três réplicas: 9.216 × 3 = 27.648 GB = 27,648 TB.

Estas são estimativas apenas do payload, usando unidades decimais. Índices, enquadramento dos registros, uploads duplicados temporários, logs operacionais e sobrecarga do sistema de arquivos exigem capacidade adicional. Aplique o ciclo de vida de 400 dias às leituras brutas canônicas, e não a cada cópia de nova tentativa. Mantenha os registros de faturamento separadamente, de acordo com a política de retenção financeira da concessionária.

2. Dimensionamento da reconexão e ingestão

A tempestade desconecta 1.200.000 × 30% = 360.000 medidores. Cada um armazena em buffer 6 × 4 = 24 leituras, resultando em 360.000 × 24 = 8.640.000 leituras acumuladas em backlog.

Com os uploads distribuídos ao longo de 600 segundos:

• Taxa do backlog: 8.640.000 / 600 = 14.400 leituras/segundo.
• Taxa simultânea de leituras ao vivo: 1.333,33 leituras/segundo.
• Pico sustentado de leituras únicas: 15.733,33 leituras/segundo.
• Vazão correspondente na rede: 15.733,33 × 200 = 3,1467 MB/segundo.

Este é o pico sustentado de dez minutos especificado, e não um limite para lotes instantâneos ou para o tráfego de novas tentativas. Distribua os uploads do backlog ao longo da janela de reconexão e aplique equidade por medidor para que as leituras ao vivo não sejam privadas de recursos.

Use gateways autenticados sem estado, um log durável replicado particionado por medidor, grupos de consumidores independentes, armazenamento canônico, uma projeção para o painel e um processador de vazamentos. Provisione gateways para no mínimo 60.000 tentativas de upload/segundo e consumidores a jusante para 30.000 leituras únicas/segundo. Isso oferece margem para novas tentativas; não pressupõe que as novas tentativas tenham um máximo matematicamente limitado.

Confirme cada leitura somente após a persistência em quórum durável, com réplicas em domínios de falha distintos. Confirmações parciais de lote identificam com precisão quais registros estão duráveis. Registros não confirmados permanecem elegíveis para nova tentativa. Os gateways confirmam bem dentro de 30 segundos sob a carga estabelecida, evitando amplificação de novas tentativas durante a operação normal.

O próprio backlog ocupa 8.640.000 × 200 = 1,728 GB, ou 5,184 GB replicados. Reserve no mínimo 100 GB de capacidade de log replicado, com margem adicional para enquadramento. Nunca remova registros confirmados ainda não processados: estenda a retenção ou transfira para armazenamento durável caso os consumidores fiquem para trás.

As filas absorvem lotes e interrupções dos consumidores. Autoescalonamento, contrapressão e admissão priorizada protegem a durabilidade. O backlog de seis horas deixa 42 horas antes da sobrescrita do medidor; a capacidade de ingestão projetada o drena dentro da janela de upload de dez minutos. Nenhum sistema consegue recuperar leituras já sobrescritas, nem garantir a entrega durante uma interrupção que exceda o limite de buffer do medidor.

3. Corretude do faturamento e do painel

O banco de dados de faturamento garante a contagem exatamente uma vez, e não o transporte. Seu registro de intervalos possui uma restrição de unicidade em (meter_id, interval_start).

Para cada leitura consumida, uma transação de banco de dados insere o intervalo e atualiza o acumulador do período de faturamento somente se a inserção tiver êxito. Uma duplicata torna-se uma operação sem efeito. O consumidor confirma o seu offset de log somente após o commit dessa transação; falhas, portanto, resultam em reprocessamento seguro. Payloads conflitantes para uma mesma identidade são colocados em quarentena, e não substituem silenciosamente um valor já faturado. Correções aprovadas usam um registro de ajustes explícito.

O faturamento só é encerrado após a reconciliação de completude. Leituras ausentes permanecem como exceções que exigem política da concessionária, nunca como consumo inventado. Isso garante que cada intervalo válido recebido seja contado uma única vez, apesar das novas tentativas.

O painel faz upsert independentemente da mesma chave. Monitore a latência entre a chegada e a visibilidade e provisione seu caminho normal para a meta do percentil 99 de cinco minutos. Durante tempestades, escale os consumidores e drene o backlog em até 60 minutos. Exiba o horário da medição e a atualidade dos dados, para que leituras históricas tardias não apareçam como atuais.

4. Detecção de vazamentos em tempo de evento

O processamento de vazamentos usa interval_start, nunca a ordem de chegada. Armazene as leituras deduplicadas em um mapa ordenado de intervalos por medidor. Um alerta candidato exige 96 inícios de intervalo adjacentes, espaçados exatamente em 15 minutos, cada um com vazão diferente de zero.

Leituras tardias podem conectar fragmentos antes separados; por isso, alertar imediatamente sobre cada fragmento observado poderia gerar várias notificações para uma única sequência final. Em vez disso, emita notificações somente a partir de um prefixo de tempo de evento finalizado.

Adicione um protocolo de completude de upload por medidor: um medidor informa uma fronteira somente depois que cada intervalo anterior foi confirmado de forma durável ou declarado explicitamente indisponível por ter expirado. O servidor avança a fronteira de processamento somente depois que essas leituras confirmadas chegaram ao armazenamento canônico. Novas tentativas pendentes e lotes em trânsito impedem o avanço prematuro. Persista essas fronteiras e as declarações de lacuna.

Não presuma que “48 horas de idade” sozinho comprova completude: a transmissão e o processamento podem acrescentar atraso. Medidores desconectados não conseguem avançar sua fronteira, portanto seus alertas aguardam a reconciliação. Nenhum requisito de latência de alerta foi especificado.

Um intervalo ausente é desconhecido, não zero e não diferente de zero. Ele impede que qualquer janela de 96 intervalos que o atravesse seja qualificada. Enquanto não resolvido, ele também impede a finalização. Uma vez explicitamente finalizado como indisponível, interrompe a sequência verificada consecutiva, sem afirmar que a água deixou de fluir.

Processe os intervalos finalizados em ordem cronológica, mantendo a contagem consecutiva de valores diferentes de zero e um indicador de alerta emitido. Ao atingir a contagem de 96, crie transacionalmente uma entrada na caixa de saída de notificações, identificada pelo medidor e pelo início da sequência verificada. Intervalos diferentes de zero subsequentes mantêm o indicador. Um intervalo finalizado como zero ou indisponível encerra essa sequência verificada. Identificadores de notificação duráveis e um endpoint de entrega idempotente impedem que a reexecução crie outro alerta lógico.

5. Exatamente três compensações

1. Escolhido: confirmação com log durável primeiro. Rejeitado: confirmar antes da persistência. As gravações em quórum aumentam a latência e o custo de infraestrutura, mas as novas tentativas permanecem seguras e as leituras confirmadas sobrevivem a falhas dos gateways.

2. Escolhido: registro transacional de intervalos para faturamento. Rejeitado: confiar na entrega exatamente uma vez no nível de transporte. A unicidade no banco de dados e as atualizações atômicas do acumulador custam capacidade de escrita, mas protegem diretamente o invariante de contagem financeira diante de reprocessamentos e falhas.

3. Escolhido: alertas de vazamento finalizados em tempo de evento. Rejeitado: alertas imediatos por ordem de chegada com correções posteriores. O rastreamento de completude atrasa as notificações, especialmente após desconexões, mas impede que dados tardios em buffer unam fragmentos já notificados de forma independente em uma única sequência.

Projeto e capacidade

Use um log de ingestão durável e replicado entre os gateways voltados para os medidores e os serviços a jusante. Os gateways autenticam os medidores, validam o carimbo de tempo do intervalo e a carga útil, e publicam as leituras com chave em (meter_id, interval_start). Particione o log por ID do medidor, de modo que os registros de um mesmo medidor fiquem ordenados, ao mesmo tempo em que os medidores são distribuídos entre as partições. Confirme um envio somente depois que o registro for replicado de forma durável para as réplicas exigidas. Se a confirmação se perder, o medidor pode tentar novamente; o sistema aceita a duplicata em vez de arriscar a perda de dados.

A taxa em regime estável é:

• 1.200.000 medidores ÷ 900 segundos por intervalo = 1.333,3 leituras/segundo.
• 1.200.000 × 96 intervalos/dia = 115.200.000 leituras/dia.
• 115.200.000 × 200 bytes = 23.040.000.000 bytes/dia = 23,04 GB/dia.
• Em 400 dias: 23,04 GB × 400 = 9.216 GB = 9,216 TB de leituras brutas. Com três réplicas: 9,216 TB × 3 = 27,648 TB.

Estes números usam o tamanho de registro especificado na transmissão e unidades decimais; eles excluem índices, sobrecarga do formato de armazenamento e margem operacional. Armazene o histórico bruto completo em um arquivo replicado e particionado por tempo, e retenha o log de ingestão pelo tempo suficiente para cobrir a recuperação normal dos consumidores, em vez de usá-lo como o arquivo de 400 dias.

Para a tempestade descrita, 30% × 1.200.000 = 360.000 medidores são afetados. Seis horas contêm 6 × 4 = 24 intervalos, então os medidores que se reconectam enviam 360.000 × 24 = 8.640.000 leituras armazenadas em buffer. Distribuídas ao longo de 10 minutos, isso resulta em 8.640.000 ÷ 600 = 14.400 leituras/segundo. Somando o tráfego ao vivo de todos os medidores, 1.333,3 leituras/segundo, obtém-se um pico nominal de aproximadamente 15.733 leituras/segundo. A carga de chegada de 10 minutos é de cerca de 9,44 milhões × 200 bytes = 1,888 GB, incluindo aproximadamente 800.000 leituras ao vivo.

Provisione capacidade de gateway e de escrita no log para pelo menos 32.000 leituras/segundo sustentadas, cerca de duas vezes o pico calculado, e reserve capacidade de fila para pelo menos toda a janela de chegada de 9,44 milhões de registros, com espaço adicional para novas tentativas e atraso de processamento. O log replicado absorve a rajada enquanto os consumidores se atualizam; consumidores escaláveis de forma independente então gravam o arquivo, o armazenamento de cobrança, a visão do painel e o estado de alertas. Essa capacidade absorve a rajada descrita sem descartar leituras aceitas. O limite de sobrescrita de 48 horas do medidor é uma limitação a montante: leituras sobrescritas antes da reconexão não podem ser recuperadas pelo backend.

Corretude e disponibilização

A cobrança usa uma tabela canônica de leituras com uma restrição de unicidade imposta pelo banco de dados sobre (meter_id, interval_start). Seu destino executa uma operação de inserção-ou-conflito: a primeira cópia insere a leitura, e novas tentativas ou envios repetidos com a mesma chave não criam outro intervalo faturável. A cobrança agrega somente essa tabela canônica. O destino confirma a leitura e o progresso do consumidor do log de forma transacional, ou usa gravações seguras para reprocessamento, para que uma falha seguida de reprocessamento não cause contagem dupla. Uma duplicata com valores conflitantes deve ser sinalizada para investigação, em vez de ser silenciosamente contabilizada como outro intervalo.

Um consumidor separado mantém uma visão materializada voltada ao cliente. Ele faz upsert pela mesma chave de intervalo e atualiza a última leitura exibida de acordo com o tempo do intervalo, e não pela ordem de chegada. Monitore a latência de ponta a ponta entre chegada e visualização e escale consumidores e partições para atingir a meta de operação normal de que 99% estejam visíveis em cinco minutos. Durante a rajada especificada, a visão pode atrasar até 60 minutos; o log durável e o arquivo permanecem íntegros enquanto ela se recupera. Os clientes podem ver informações de atualidade, para que uma visão atrasada não seja confundida com uma leitura atual.

A detecção de vazamentos é um cálculo de tempo de evento, indexado por medidor e ordenado por interval_start. Deduplique cada intervalo antes de avaliá-lo, e mantenha os resultados dos intervalos para que uma leitura tardia possa atualizar o estado e provocar o recálculo da sequência de intervalos afetada. Não decida que um intervalo está ausente apenas porque um intervalo posterior chegou primeiro. Avance uma marca d'água de completude somente depois que todos os registros do log recebidos até o tempo de ingestão relevante tiverem sido processados, e defina-a com pelo menos 48 horas de atraso em relação ao tempo de ingestão, com margem operacional extra para atraso de fila. Isso considera o período máximo de armazenamento em buffer do medidor.

Um intervalo ausente é tratado como não mostrando fluxo diferente de zero: quando ele está atrás da marca d'água de completude e não existe leitura, ele interrompe uma sequência consecutiva. Antes disso, ele está não resolvido, e não é zero. Quando 96 intervalos consecutivos finalizados mostrarem todos fluxo diferente de zero, emita um alerta para essa sequência. Persista uma identidade de alerta baseada no medidor e na sequência, e use uma caixa de saída de notificações idempotente, para que o reprocessamento não envie outro alerta para a mesma sequência. Aguardar a completude pode atrasar um alerta em até o horizonte de atraso, mas evita que uma leitura tardia e fora de ordem produza um resultado incorreto.

Exatamente três compromissos

1. Escolhido: log replicado antes dos consumidores. Rejeitado: gravações síncronas dos gateways em todos os destinos. O log adiciona infraestrutura e alguma latência, mas armazena em buffer as rajadas de reconexão e isola a ingestão de serviços lentos de cobrança ou painel.
2. Escolhido: visões materializadas do painel atualizadas de forma assíncrona. Rejeitado: distribuição síncrona para o painel durante a ingestão. Atualizações eventuais atendem às metas declaradas de cinco minutos em operação normal e 60 minutos durante a rajada, mantendo as consultas dos clientes rápidas; a distribuição síncrona acoplaria a aceitação dos medidores à disponibilidade do painel e à carga da rajada.
3. Escolhido: alertas de vazamento baseados em marca d'água e sensíveis a dados atrasados. Rejeitado: alertas imediatos pela ordem de chegada. Aguardar a janela limitada de atraso custa velocidade no alerta, mas sustenta sequências corretas baseadas em intervalos e o tratamento explícito de dados ausentes.

1. Estimativas de capacidade

Taxa em regime permanente

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

Volume bruto por dia

• Leituras por dia: 1.200.000 × 96 intervalos = 115,2 M
• Bytes por dia: 115,2 M × 200 B = 23,04 × 10^9 B = 23,04 GB/dia

Armazenamento bruto para a retenção

• Uma cópia: 23,04 GB × 400 dias = 9.216 GB = 9,216 TB
• Com 3 réplicas: 9,216 TB × 3 = 27,65 TB

Os índices e a sobrecarga de compactação vêm além disso. A compressão colunar provavelmente reduzirá bastante esse valor.

2. Rajada de reconexão

Taxa de pico

• Medidores offline: 30% × 1,2 M = 360.000
• Leituras armazenadas em buffer por medidor: 6 h × 4 intervalos/h = 24
• Backlog total: 360.000 × 24 = 8,64 M leituras
• Todos os medidores se reconectam em até 600 s, distribuídos uniformemente: 8,64 M ÷ 600 = 14.400 leituras/s
• Some o tráfego ao vivo: 14.400 + 1.333 = 15.733 leituras/s. Isso equivale a cerca de 11,8× o regime permanente, ou aproximadamente 3,15 MB/s.
• Se as confirmações ficarem mais lentas, as retentativas podem dobrar esse valor, então provisiono para cerca de 32.000 leituras/s.

Como o projeto absorve a rajada

1. Gateways sem estado (MQTT/HTTPS atrás de um balanceador de carga) verificam as credenciais dos medidores e o esquema da carga útil. Eles são dimensionados para 32 mil/s mais capacidade ociosa N+1.
2. Log durável (Kafka, fator de replicação 3, acks=all, particionado por meter_id). O gateway envia ao medidor sua confirmação somente após a escrita no log ser confirmada. Assim, toda leitura confirmada é durável, e uma leitura não confirmada é reenviada pelo medidor. Em ambos os casos, nada é perdido. Alguns MB/s são trivial para o Kafka, então as escritas continuam rápidas e as confirmações retornam bem dentro do tempo limite de 30 s, o que mantém as retentativas raras.
3. Dois tópicos. O gateway envia para live as leituras com interval_start nos últimos 30 minutos, e tudo o que for mais antigo para backfill. Os consumidores esvaziam live primeiro, então a meta de 5 minutos do painel se mantém para os dados ao vivo mesmo durante uma tempestade.
4. Os consumidores a jusante absorvem o backlog. Eles não precisam acompanhar o pico. A 5.000 leituras/s, o backlog de 8,64 M é zerado em cerca de 29 minutos, dentro do limite relaxado de 60 minutos do painel. A retenção do Kafka é de 7 dias, então mesmo uma falha do consumidor não causa perda de dados.
5. Jitter no lado do medidor. O firmware adiciona um backoff aleatório na reconexão e nas retentativas, o que suaviza ainda mais a rajada.

3. Cobrança exatamente uma vez

O banco de dados do razão de cobrança garante a contagem exatamente uma vez. Ele usa a chave primária (meter_id, interval_start).

• O consumidor de cobrança escreve com INSERT … ON CONFLICT (meter_id, interval_start) DO NOTHING.
• Envios repetidos, reenvios do gateway e reprocessamentos do consumidor após uma falha caem todos no conflito e não alteram nada.
• Os offsets do Kafka são confirmados somente depois que a escrita no banco de dados tem sucesso. Isso resulta em entrega pelo menos uma vez em um destino idempotente, o que, na prática, equivale a exatamente uma vez.
• Se uma duplicata chegar com um valor diferente, o primeiro valor armazenado é mantido e o conflito vai para uma fila de conciliação. Ele nunca é somado.
• Os totais de cobrança são calculados somente a partir dessa tabela desduplicada.
• O armazenamento do painel (um banco de dados de séries temporais) usa a mesma chave como upsert, então seus gráficos também não têm duplicatas.

4. Alertas de vazamento em tempo de evento

Um processador de fluxo com estado (por exemplo, Flink), particionado por meter_id, lê os dois tópicos e trabalha em tempo de evento (interval_start), não em tempo de chegada.

Estado por medidor

• Um mapa de bits sobre os últimos 296 intervalos (48 h mais 24 h de histórico mais margem). Cada posição é não zero, zero ou desconhecida.
• As sequências atuais, cada uma identificada pelo seu primeiro intervalo.
• Um indicador para cada sequência, registrando se ela já disparou um alerta.

Regras

• Uma leitura atrasada preenche a sua posição, onde quer que ela esteja. A ordem de chegada não importa, e uma duplicata não tem efeito.
• Um alerta é disparado somente quando 96 posições consecutivas estão todas presentes e todas não zero. Como toda posição precisa ser preenchida com dados confirmados, uma chegada posterior nunca pode invalidar um alerta que já foi disparado.
• Intervalo ausente. Enquanto uma posição tiver menos de 48 h (mais 1 h de tolerância), ela é desconhecida. Ela não estende nem quebra uma sequência, e o alerta simplesmente aguarda. Depois que interval_start + 49 h tiver passado, a leitura nunca mais poderá chegar, então a posição é finalizada como ausente, o que quebra a sequência. Um alerta nunca é disparado com base em dados não verificados.
• Um alerta por sequência. O registro de alerta é identificado por (meter_id, streak_start) em uma tabela de alertas com restrição de unicidade, então um evento reprocessado não pode enviar um segundo alerta. Uma sequência termina em uma leitura zero ou em uma lacuna finalizada. Se uma leitura atrasada preencher uma lacuna e unir duas sequências, a sequência mesclada mantém o streak_start mais antigo e herda o indicador de "já alertada", então ainda recebe apenas um alerta.
• O estado é salvo em ponto de controle no armazenamento durável. Após uma reinicialização, o processador reprocessa a partir dos offsets confirmados e reconstrói o mesmo estado.

5. Compromissos

1. Quando confirmar uma leitura

   • Escolhido: confirmar após a escrita replicada no log. Isso garante que nenhuma leitura seja perdida e custa alguns milissegundos por confirmação.
   • Rejeitado: confirmar no recebimento, a partir da memória. É mais rápido, mas uma falha do gateway descartaria silenciosamente leituras que o medidor já apagou do seu buffer.

2. Como remover duplicatas

   • Escolhido: escritas idempotentes com uma chave única no razão de cobrança. Isso é simples, fácil de verificar e sobrevive a qualquer reprocessamento, de qualquer origem.
   • Rejeitado: transações Kafka exatamente uma vez de ponta a ponta. Elas não detectam duplicatas criadas antes do Kafka, como um medidor que reenvia após perder uma confirmação. Além disso, adicionam custo de coordenação e são difíceis de operar.

3. Como tratar um intervalo ausente na detecção de vazamentos

   • Escolhido: uma lacuna finalizada quebra a sequência. Isso significa que não há alertas falsos baseados em dados estimados, e cada alerta pode ser respaldado perante o cliente. O custo é que um vazamento real com uma lacuna de conectividade de 48 horas pode ser detectado com atraso.
   • Rejeitado: tratar lacunas como continuação da sequência, ou preenchê-las a partir de leituras vizinhas. Isso detecta mais vazamentos, mas gera alertas com base em leituras que nunca existiram e torna a regra de "um alerta por sequência" pouco clara.

Resumo

• Capacidade: 1.333 leituras/s em regime permanente, 23,04 GB/dia, 27,65 TB armazenados com 3 réplicas.
• Rajada: pico de 15.733 leituras/s, absorvido por um log durável que confirma somente após uma escrita confirmada e por prioridade para os dados ao vivo.
• Cobrança: a contagem exatamente uma vez é garantida pela chave única do razão.
• Alertas de vazamento: calculados em tempo de evento, nunca disparados com base em dados não verificados, e limitados a um por sequência.

1. Estimativas de capacidade

Estado estacionário

• Intervalos por dia: 24 h × 4 = 96.
• Leituras por segundo: 1.200.000 / 900 s = ≈1.333 leituras/s. Isso equivale a cerca de 267 KB/s na rede.
• Leituras por dia: 1.200.000 × 96 = 115,2 M.
• Volume bruto por dia: 115,2 M × 200 B = 23,04 GB, portanto ≈23 GB/dia.
• Retenção: 23,04 GB × 400 dias = 9.216 GB ≈ 9,2 TB de uma cópia.
• Com 3 réplicas: 9,216 TB × 3 = ≈27,6 TB (27.648 GB).
• Isso não inclui índices nem compressão. Eu adicionaria cerca de 30% de folga, resultando em um valor provisionado de cerca de 36 TB.

2. Rajada de reconexão

• Medidores afetados: 30% × 1,2 M = 360.000.
• Intervalos armazenados em buffer por medidor: 6 h × 4 = 24.
• Acúmulo: 360.000 × 24 = 8,64 M de leituras, o que equivale a 1,73 GB.
• Janela de envio: 10 min = 600 s, distribuídos uniformemente, então a taxa do acúmulo = 8,64 M / 600 = 14.400/s.
• O tráfego ao vivo continua em 1.333/s.
• Pico = 14.400 + 1.333 ≈ 15.733 leituras/s, cerca de 11,8× o estado estacionário, ou cerca de 3,1 MB/s.

As retentativas somam-se a isso. Se as confirmações forem atrasadas além de 30 s, os medidores reenviam. Por isso, dimensiono o caminho de ingestão para 2× o pico, cerca de 32.000/s. Na prática, isso significa 8 nós de ingestão sem estado, com cerca de 5.000/s cada, mais N+2 de reserva.

Como nada se perde

1. O gateway de ingestão valida uma leitura e a anexa a um log durável e particionado, como o Kafka. Ele usa acks=all, fator de replicação 3 e min.insync.replicas=2. Ele envia ao medidor a confirmação somente depois que a anexação é bem-sucedida.
2. O log tem 48 partições com chave meter_id e mantém 7 dias de dados. A rajada é de cerca de 3 MB/s, o que é trivial para o log. Os consumidores podem ficar atrasados por minutos ou horas sem perda.
3. Se o gateway ou o log estiver sobrecarregado, ele retorna 503 ou nenhuma confirmação. O medidor mantém a leitura e tenta novamente. Seu buffer de 48 horas cobre uma interrupção de 6 horas mais a recuperação, o que deixa cerca de 42 horas de margem. Assim, a contrapressão nunca descarta dados.
4. Os consumidores a jusante (gravador de faturamento, projetor do painel, processador de vazamentos) têm grupos de consumidores separados. Eles confirmam os offsets somente depois que suas gravações têm sucesso, de modo que uma falha causa reprocessamento, não perda.
5. Os consumidores são dimensionados para cerca de 30.000/s. O acúmulo de 8,64 M é então drenado em cerca de 5 minutos, bem dentro do orçamento relaxado de 60 minutos do painel. Em operação normal, o atraso permanece em segundos, o que atende à meta de 5 minutos para 99% das leituras.

3. Faturamento exatamente uma vez

A entrega é pelo menos uma vez em todos os pontos: retentativas do medidor, retentativas do gateway e reprocessamentos do log. O efeito exatamente uma vez é garantido por um único componente: o armazenamento de leituras, um armazenamento SQL replicado (3 réplicas, particionado por meter_id). Ele tem uma chave primária (meter_id, interval_start).

• O gravador de faturamento executa INSERT … ON CONFLICT DO NOTHING. Uma duplicata não tem efeito, seja ela proveniente de uma retentativa do medidor, de um reprocessamento ou de uma reinicialização do consumidor.
• Os totais de faturamento são calculados consultando esta tabela. Eles nunca são mantidos como contadores de stream que poderiam ser incrementados duas vezes.
• O interval_start é definido pelo medidor e alinhado à grade de 15 minutos. O gateway rejeita valores desalinhados e os coloca em quarentena.
• Se uma chave duplicada chegar com um conteúdo diferente, a primeira gravação prevalece. O conflito é registrado em uma tabela de discrepâncias para revisão, de modo que o faturamento nunca seja alterado silenciosamente.
• Os consumidores a jusante agem somente sobre as linhas que a inserção informa como recém-criadas. Por isso, o painel e o processador de vazamentos também são deduplicados.

Este armazenamento também é o armazenamento bruto. Seus 27,6 TB são o valor replicado calculado acima.

4. Alertas de vazamento com dados atrasados e fora de ordem

A regra é avaliada pelo interval_start, portanto o processador usa tempo do evento e não mantém janelas baseadas no tempo de chegada. Trata-se de um job de stream com estado, com chave meter_id, que consome somente leituras recém-inseridas.

Estado por medidor (cerca de 70 bytes):

• Um anel de 2 bits por intervalo, cobrindo os últimos 288 intervalos (72 horas). Os três valores são desconhecido, zero e não zero.
• alerted_range = [start, end] para a última sequência com alerta.

A cada leitura no intervalo t:

1. Defina o slot de t.
2. Se ele for não zero, varra à esquerda e à direita a partir de t para encontrar a sequência contígua máxima de intervalos não zero que contém t.
3. Se o comprimento da sequência for ≥ 96 e ela não se sobrepuser a alerted_range, emita um alerta. Em seguida, defina alerted_range como a sequência.
4. Se a sequência se sobrepuser a alerted_range, estenda alerted_range e não emita nada.

Como o estado depende apenas do conjunto de leituras e não da ordem delas, um lote que chega em ordem inversa produz o mesmo resultado que a chegada em ordem. Uma leitura atrasada que preenche um buraco pode unir duas sequências menores em uma sequência de 96, e o alerta é disparado nesse momento. Uma leitura zero encerra a sequência. A próxima sequência qualificada é uma nova sequência e pode gerar alerta novamente.

Os alertas são gravados em uma outbox na mesma transação de alerted_range, e uma chave única (meter_id, streak_start) reforça essa garantia. Reprocessamentos e reinicializações, portanto, não podem enviar um segundo alerta.

Intervalos ausentes. Um intervalo ausente é desconhecido. Não é zero nem não zero, e nunca é interpolado. Ele quebra a contiguidade, portanto nenhum alerta é disparado através de uma lacuna. A sequência é reavaliada automaticamente se a leitura ausente chegar depois, o que pode acontecer até 48 horas após o intervalo. Após 48 horas, ela é perdida permanentemente e a sequência permanece interrompida. Isso favorece a ausência de alarmes falsos, ao custo de um possível alerta atrasado ou perdido após uma interrupção longa. Se ficar claro que alertas perdidos são piores do que alertas falsos, pode-se acrescentar um aviso separado de "lacuna de dados".

Estado com mais de 72 horas é removido. Leituras mais antigas que o limite de 48 horas não podem chegar legitimamente, então são registradas em log e ignoradas.

5. Compensações

1. Quando confirmar ao medidor.

• Escolhido: confirmar após a anexação ao log durável.
• Rejeitado: confirmar após a gravação no armazenamento SQL.
• Motivo: a gravação no log é uma anexação rápida, não afetada pela carga do banco de dados. Assim, uma rajada não pode elevar a latência de confirmação além de 30 s e disparar tempestades de retentativas.
• Custo: os dados ainda não são consultáveis no momento da confirmação. Isso é aceitável porque o faturamento tolera atraso e o painel permite 60 minutos durante uma rajada.

2. Onde deduplicar.

• Escolhido: uma restrição de chave primária no banco de dados com inserção idempotente.
• Rejeitado: deduplicação no nível do stream, ou seja, transações do Kafka ou um cache "visto" em memória ou baseado em filtro de Bloom.
• Motivo: as transações do Kafka cobrem apenas o trecho do log, não as retentativas do medidor que criam novas mensagens. Um cache é limitado e pode ser perdido em uma reinicialização, e um filtro de Bloom tem falsos positivos, o que descartaria uma leitura faturável.
• Custo: cada duplicata custa uma inserção conflitante e barata. Com 2× o pico, isso fica bem dentro da capacidade do armazenamento.

3. Como avaliar vazamentos.

• Escolhido: um bitmap por medidor, orientado a eventos e avaliado a cada nova leitura.
• Rejeitado: uma varredura periódica em lote ou janelas fechadas por marca d'água.
• Motivo: o bitmap é independente da ordem e tolera atraso de 48 horas sem nenhum atraso de marca d'água, de modo que os alertas são disparados assim que o último intervalo ausente chega. As janelas precisariam de uma marca d'água de 48 horas e atrasariam todos os alertas, ou então emitiriam resultados errados que exigiriam correção posterior.
• Custo: cerca de 85 MB de estado com chave (1,2 M × cerca de 70 B) e uma recuperação cuidadosa do estado a partir de checkpoints.

Arquitetura Regional de Ingestão de Medidores Inteligentes de Água

1. Estimativas de Capacidade e Aritmética

Leituras por Segundo em Regime Permanente

• Frota de medidores: $1,200,000$ medidores.
• Intervalo: A cada 15 minutos ($15 \times 60 = 900$ segundos).
• Cálculos:
  $$\text{Vazão em Regime Permanente} = \frac{1,200,000\text{ leituras}}{900\text{ segundos}} = 1,333.33\text{ leituras/segundo}$$

Volume Bruto de Dados por Dia

• Leituras por medidor por dia: $\frac{24\text{ horas} \times 60\text{ minutos}}{15\text{ minutos}} = 96\text{ leituras/dia}$.
• Total de leituras diárias: $1,200,000 \times 96 = 115,200,000\text{ leituras/dia}$.
• Tamanho da carga útil: $200\text{ bytes/leitura}$ na transmissão.
• Cálculos (usando unidades decimais, onde $1\text{ GB} = 10^9\text{ bytes}$):
  $$\text{Volume Diário de Ingestão} = 115,200,000 \times 200\text{ bytes} = 23,040,000,000\text{ bytes} = 23.04\text{ GB/dia}$$

Armazenamento Bruto para Retenção de 400 Dias (com 3 Réplicas)

• Armazenamento de 400 dias com uma única cópia:
  $$400\text{ dias} \times 23.04\text{ GB/dia} = 9,216\text{ GB} = 9.216\text{ TB}$$
• Armazenamento com replicação tripla:
  $$9,216\text{ GB} \times 3 = 27,648\text{ GB} = 27.648\text{ TB}$$

2. Dimensionamento e Absorção de Rajadas na Reconexão

Cálculos do Pico de Rajada

• Medidores afetados: $30% \text{ de } 1,200,000 = 360,000\text{ medidores}$.
• Duração da interrupção: 6 horas = $6 \times 4 = 24\text{ intervalos}$ acumulados por medidor.
• Total de leituras armazenadas em buffer: $360,000 \times 24 = 8,640,000\text{ leituras}$.
• Janela de reconexão: 10 minutos = $600\text{ segundos}$ (distribuídos uniformemente).
• Taxa de chegada da rajada a partir do backlog:
  $$\text{Taxa de Rajada} = \frac{8,640,000\text{ leituras}}{600\text{ segundos}} = 14,400\text{ leituras/segundo}$$
• Tráfego simultâneo de regime permanente ativo: $1,333.33\text{ leituras/segundo}$.
• Vazão combinada de pico:
  $$\text{Taxa de Pico} = 14,400 + 1,333.33 = 15,733.33\text{ leituras/segundo} \approx 15,734\text{ leituras/segundo}$$
• Largura de banda de ingresso no pico:
  $$15,734\text{ leituras/s} \times 200\text{ bytes} = 3,146,800\text{ bytes/s} \approx 3.15\text{ MB/s (25.2 Mbps)}$$

Estratégia de Absorção

1. Terminação na Borda e ACK Rápido: Uma frota de API Gateways sem estado, escalados horizontalmente, fica à frente do endpoint de ingestão. Como os medidores tentam novamente após 30 segundos sem um ACK, o gateway verifica a estrutura do lote e anexa imediatamente a carga útil a um log de commit distribuído (Apache Kafka) antes de confirmar HTTP 202/200 em menos de 50 milissegundos. Isso elimina timeouts de cliente sem confirmação e retentativas em cascata.
2. Desacoplamento por Fila: O Kafka atua como um amortecedor durável de choques. As partições são divididas estritamente pelo hash de meter_id (usando 64 partições para lidar com conforto com até $50,000\text{ msgs/s}$). Mesmo que o processamento dos consumidores a jusante desacelere durante a rajada, o caminho de ingresso persiste o fluxo de dados de 3.15 MB/s diretamente em disco, sem aplicar contrapressão aos gateways de borda.
3. Limitação de Consumo do Painel do Cliente: Os workers de projeção do painel do cliente limitam o consumo de ingestão, atendendo facilmente ao SLO de rajada relaxado de 60 minutos, enquanto garantem capacidade de consumo dedicada aos processadores de fluxo críticos de cobrança e alertas.

3. Ingestão de Cobrança Exatamente Uma Vez

Retentativas de rede inevitavelmente produzem mensagens duplicadas com (meter_id, interval_start) idênticos. O projeto garante contagem exatamente uma vez na Camada de Carga de Armazenamento de Cobrança (Pipeline de Ingestão de Cobrança) por meio de uma combinação de upserts idempotentes e restrições de chave primária relacional.

Mecanismo

• Chave Natural: A chave primária do razão de staging de cobrança é (meter_id, interval_start).
• Limite de Deduplicação: Um carregador de lotes transacional consome eventos do Kafka e os grava em um banco de dados de razão de cobrança imutável e somente de inserção, usando semântica de upsert determinística (INSERT ... ON CONFLICT (meter_id, interval_start) DO NOTHING).
• Idempotência em Duas Fases:
  1. Antes do staging, um processador de fluxo com estado (por exemplo, Apache Flink) usa uma tabela de estado com suporte em RocksDB, mantendo um filtro de deduplicação deslizante de 48 horas (correspondendo ao buffer máximo de 48 horas do medidor). Retentativas de rede duplicadas que ocorram dentro dessa janela são descartadas imediatamente.
  2. Quaisquer retentativas que contornem ou sejam recarregadas após reinicializações dos workers atingem a restrição de índice único do banco de dados em (meter_id, interval_start). As consultas de agregação de cobrança somam exclusivamente este razão deduplicado, tornando matematicamente impossível a contagem em excesso.

4. Motor de Alertas de Vazamento com Leituras Fora de Ordem / Ausentes

Lógica de Detecção

Um vazamento contínuo é definido como 96 intervalos consecutivos de 15 minutos (24 horas contínuas) de fluxo diferente de zero, avaliados estritamente por interval_start.

Pipeline de Processamento de Fluxo

1. Marcas d'Água e Atraso Permitido: Uma topologia de streaming (Apache Flink) mantém um estado com chave por medidor, rastreando intervalos contíguos. Como os medidores podem armazenar em buffer até 48 horas, o job de streaming configura um limite de atraso permitido de 48 horas. Leituras chegadas com atraso são roteadas de volta ao estado com chave do medidor, em vez de descartadas.
2. Conjunto de Bits de Contiguidade / Árvore de Intervalos: Cada medidor mantém uma estrutura de estado de intervalos contendo os intervalos avaliados mais recentes, ordenados por interval_start. Quando chega uma rajada fora de ordem, os intervalos preenchem seus slots correspondentes na linha do tempo cronológica.
3. Tratamento de Intervalos Ausentes:
   • Se um intervalo estiver ausente devido a perda de pacotes, desvio de relógio ou exceder o limite de sobrescrita do buffer de 48 horas do medidor, ele é tratado como um fluxo contíguo desconhecido/interrompido.
   • Como a especificação exige 96 intervalos consecutivos de fluxo não zero confirmado, um intervalo ausente zera a sequência ativa. O motor nunca presume fluxo ou fluxo zero para dados ausentes.
4. Garantia de Alerta Único:
   • A máquina de estados rastreia streak_count e uma flag booleana alert_emitted_for_current_streak.
   • Quando streak_count atinge 96, o motor verifica se alert_emitted_for_current_streak é false. Se for false, emite o alerta de vazamento e define a flag como true.
   • Intervalos subsequentes consecutivos não zero incrementam streak_count, mas suprimem novos alertas. Somente quando uma leitura zero (ou um intervalo ausente) quebra a sequência é streak_count zerado e alert_emitted_for_current_streak redefinido para false.

5. Compromissos Arquiteturais

Compromisso 1: Momento da Confirmação de Ingestão

• Opção Escolhida: Confirmar o recebimento assim que as leituras brutas forem gravadas na fila de mensagens distribuída (Kafka).
• Opção Rejeitada: Confirmar o recebimento somente após as gravações serem concluídas no banco de dados histórico de longo prazo e nas tabelas de cobrança.
• Justificativa: Um ACK completo de ponta a ponta durante uma tempestade de reconexão de 15,734 rps arrisca atingir gargalos de I/O do banco de dados. Se as respostas excederem o timeout de 30 segundos do medidor, os medidores tentam novamente, aumentando a carga de ingresso exponencialmente. O ACK no nível da fila garante persistência em milissegundos e interrompe as retentativas imediatamente.

Compromisso 2: Arquitetura de Computação para Detecção de Vazamentos

• Opção Escolhida: Processador de streaming com estado e tempo de evento (Apache Flink com backend de estado RocksDB).
• Opção Rejeitada: Consultas SQL em lote periódicas sobre tabelas de banco de dados analítico (por exemplo, executadas a cada 15 minutos).
• Justificativa: Varreduras SQL em lote sobre milhões de medidores com chegadas tardias fora de ordem exigem consultar janelas deslizantes enormes de vários dias sobre bilhões de linhas para reconstruir lacunas e sequências. O motor de streaming com estado avalia o estado deslizante de forma incremental à medida que os dados chegam, mantendo a latência mínima e eliminando varreduras repetidas de tabelas.

Compromisso 3: Armazenamento de Dados do Painel do Cliente

• Opção Escolhida: Armazenamento NoSQL/séries temporais pré-agregado e otimizado para leitura (por exemplo, Apache Cassandra / ScyllaDB).
• Opção Rejeitada: Consultas sob demanda diretamente no banco de dados relacional normalizado de cobrança.
• Justificativa: As consultas do painel apresentam alta concorrência de leitura e requisitos de consistência flexíveis (permitindo até 60 minutos de atraso durante rajadas). Desacoplar as leituras do painel do armazenamento de cobrança protege as transações financeiras de picos de consultas dos clientes e permite escalonamento horizontal com 23+ GB por dia.

Arquitetura de Ingestão de Medidores Inteligentes de Água

1. Estimativas de Capacidade e Cálculos

Para construir um back-end robusto para 1,2 milhão de medidores inteligentes, começamos com o dimensionamento determinístico de capacidade e armazenamento.

• Leituras por segundo em regime estacionário: Cada medidor transmite uma leitura a cada 15 minutos (900 segundos). Para 1.200.000 medidores, a taxa média de ingestão é $1.200.000 / 900 = 1.333,33$ leituras por segundo.
• Volume de dados brutos por dia: Com 1.333,33 leituras por segundo, o número total de leituras diárias é $1.333,33 \times 86.400 = 115.200.000$ leituras/dia. Com cada leitura dimensionada em 200 bytes na transmissão, o volume diário de dados brutos é $115.200.000 \times 200 \text{ bytes} = 23.040.000.000 \text{ bytes/dia}$ (ou 23,04 GB/dia).
• Armazenamento bruto para todo o período de retenção, incluindo replicação: Os dados devem ser retidos por 400 dias com 3 réplicas. O cálculo total de armazenamento é $23,04 \text{ GB/dia} \times 400 \text{ dias} \times 3 \text{ réplicas} = 27.648 \text{ GB}$ (ou 27,64 TB).

2. Caminho de Ingestão e Dimensionamento de Rajadas de Reconexão

Quando ocorre uma tempestade grande, 30% dos medidores ($360.000$ medidores) perdem conectividade por 6 horas. Ao longo de 6 horas, cada medidor desconectado armazena em buffer $6 \times 4 = 24$ leituras. Quando a conectividade retorna, todos os 360.000 medidores enviam suas 24 leituras armazenadas em buffer, distribuídas uniformemente em uma janela de 10 minutos (600 segundos).

• Taxa de envio do buffer: A taxa de leituras históricas durante a rajada é $(360.000 \text{ medidores} \times 24 \text{ leituras}) / 600 \text{ segundos} = 8.640.000 / 600 = 14.400$ leituras por segundo.
• Taxa simultânea de leituras ao vivo: Simultaneamente, todos os 1.200.000 medidores continuam enviando suas leituras normais em tempo real a $1.333,33$ leituras por segundo.
• Taxa de ingestão de pico: A taxa total de pico é $14.400 + 1.333,33 = 15.733,33$ leituras por segundo (aproximadamente 15,7k rps).

Para absorver esse aumento súbito sem descartar nenhuma leitura, a camada de ingestão usa um broker de mensagens distribuído e escalável horizontalmente (como o Apache Kafka), particionado em 64 partições. Uma frota de API Gateway, posicionada atrás de um balanceador de carga, encerra o TLS, realiza validação rápida de esquema e grava diretamente no broker de mensagens. Como as partições do Kafka desacoplam a ingestão do processamento a jusante, o aumento súbito fica armazenado com segurança em buffer em logs de commit com suporte em disco. Os workers consumidores escalam dinamicamente com base no atraso de consumo (consumer lag), absorvendo o aumento temporário sem perda de dados.

3. Idempotência e Cobrança Exatamente Uma Vez

Os medidores repetem envios se não receberem uma confirmação em 30 segundos, o que significa que duplicatas certamente chegarão. Para garantir que a cobrança conte cada (meter_id, interval_start) exatamente uma vez, aplicamos idempotência dentro do Processador de Stream de Cobrança.

Cada payload de leitura recebido contém uma chave natural composta: meter_id e interval_start. O processador de stream de cobrança consome leituras do broker de mensagens e usa uma operação de upsert atômica contra um armazenamento de dados colunar distribuído ou um armazenamento de estado de deduplicação (como o RocksDB integrado ao Apache Flink).

Quando uma leitura chega, o processador verifica se já existe um registro para (meter_id, interval_start) que tenha sido processado e cobrado. Se a chave existir, o payload duplicado é descartado com segurança ou marcado como duplicata, garantindo zero contagem dupla. Se a chave não existir, a tabela de cobrança é atualizada e uma confirmação é enviada de volta ao broker de ingestão.

4. Dados Atrasados e Alertas de Vazamento

A detecção de vazamentos exige identificar quando um medidor apresenta fluxo diferente de zero em cada um dos 96 intervalos consecutivos de 15 minutos (cobrindo um período completo de 24 horas), avaliado estritamente pelo interval_start e não pelo horário de chegada. Para garantir que os alertas de vazamento permaneçam corretos quando leituras armazenadas em buffer chegam atrasadas e fora de ordem, empregamos Processamento de Stream em Tempo de Evento com Watermarking.

• Tratamento de dados atrasados: O processador de stream mantém janelas de estado indexadas por meter_id. Como os medidores podem armazenar dados em buffer por até 48 horas, as janelas de processamento de stream são configuradas com um limite de atraso permitido de 48 horas. Isso garante que, quando envios em lote atrasados ou reconectados chegarem, eles sejam retroativamente alocados em seus compartimentos cronológicos corretos de 15 minutos com base nos timestamps de interval_start.
• Intervalos ausentes: Se um intervalo de 15 minutos estiver totalmente ausente do stream e sua janela de atraso de 48 horas se encerrar sem receber dados, esse intervalo é explicitamente tratado como fluxo zero (ou dado ausente que quebra uma sequência contígua). Uma leitura ausente interrompe a sequência de fluxo não zero, reiniciando o contador consecutivo de 96 intervalos desse medidor.
• Disparo de alertas: Assim que um medidor acumula 96 intervalos contíguos não zero, o sistema dispara exatamente um alerta por sequência. Leituras não zero subsequentes na mesma execução contínua não geram alertas duplicados, graças a flags de deduplicação com estado armazenadas junto ao contador da sequência ativa.

5. Compromissos Arquiteturais

Para finalizar o design do nosso sistema, avaliamos três escolhas arquiteturais críticas:

1. Protocolo de Ingestão: Opção Escolhida (HTTP/REST com JSON sobre TLS) vs. Opção Rejeitada (MQTT / Sockets TCP Customizados). Embora sockets TCP customizados ou MQTT tenham menor sobrecarga de payload, HTTP/REST com JSON é amplamente suportado por módulos de gateway celulares e IoT, simplifica a depuração, integra-se nativamente com firewalls de gerenciamento de APIs existentes e acomoda facilmente o requisito de tamanho de 200 bytes na transmissão, sem exigir pilhas de protocolo de firmware especializadas.
2. Paradigma de Armazenamento: Opção Escolhida (Arquivos Parquet em Object Storage para Dados Frios + Log Distribuído para Dados Quentes) vs. Opção Rejeitada (Cluster SQL Relacional Distribuído Tradicional). Manter 400 dias de dados históricos de séries temporais mais 3 réplicas em um cluster de banco de dados relacional tradicional introduz custos de infraestrutura proibitivos e limites complexos de sharding horizontal. Ao gravar leituras brutas compactadas em arquivos Parquet colunares em object storage (por exemplo, AWS S3), consultados por mecanismos de consulta serverless, alcançamos retenção de longo prazo com custo-benefício, mantendo o caminho operacional ativo rápido.
3. Consistência do Dashboard: Opção Escolhida (Consistência Eventual via Projeções de Read-Model) vs. Opção Rejeitada (Consultas Síncronas Read-Through ao Banco de Dados). Para garantir que as consultas do dashboard permaneçam responsivas durante rajadas massivas de reconexão (15,7k rps), escolhemos projeções assíncronas de read-model que atualizam os dashboards dos clientes em até 5 minutos sob cargas normais (e que relaxam para 60 minutos durante tempestades). Rejeitamos consultas síncronas read-through porque bloquear ou consultar o armazenamento transacional primário sob rajadas de ingestão de pico causaria timeouts em cascata, esgotamento do pool de conexões do banco de dados e possível falha da ingestão.