Data Streaming processa eventos continuamente para apoiar análises e decisões operacionais. O projeto deve tratar janelas temporais, eventos atrasados, duplicações, qualidade dos dados e recuperação de falhas.
Confira!
Data Streaming é o processamento contínuo de eventos e registros à medida que são produzidos ou recebidos, permitindo criar indicadores e análises com latência menor do que cargas periódicas. Uma arquitetura de streaming compreende fontes, contratos de eventos, transporte, processamento, estado, qualidade, armazenamento e consumidores. O uso de Apache Kafka, Apache Flink ou outra tecnologia não assegura, isoladamente, processamento correto: é necessário definir event time, janelas, ordenação, duplicação, Watermarks, atraso e recuperação. No Business Intelligence, o valor está em utilizar eventos e informações operacionais para decisões oportunas, preservando a interpretação e a rastreabilidade das fontes.
Data Streaming e o tipo de decisão que suporta
Fluxo de eventos não equivale a indicador pronto
Sistemas corporativos podem emitir eventos de pedidos, pagamentos, ordens e alterações de estoque. Instalações também produzem medições, alarmes e mudanças de estado a partir de sensores e sistemas de supervisão. Um Data Stream transporta essas ocorrências continuamente, mas o evento isolado não é necessariamente uma medida validada para gestão. O BI pode precisar consolidar eventos por período, unidade e categoria, relacionando-os a registros de ERP ou CMMS. O processo deve preservar identidade e significado, e estabelecer quando um resultado é preliminar ou aprovado. Baixa latência de transporte não elimina atraso de fechamento ou correção posterior.
Considere um contador de entradas em uma unidade comercial. Uma sequência de eventos pode permitir avaliar variação de fluxo em janelas curtas, porém as contagens podem apresentar duplicações, lacunas ou mudanças de calibração. Combinar o resultado com faturamento exige alinhamento de horários e finalidade, sem pressupor identificação individual ou causalidade. O modelo deve conservar estados de qualidade e atualização. Se a origem deixa de transmitir, a ausência de eventos não comprova ausência de movimento. O indicador deve mostrar falta de dados, e não normalidade. A utilidade do streaming depende dessa semântica.
Batch, micro-batch e streaming contínuo
Batch executa processamento em intervalos; micro-batch processa grupos menores com frequência, e streaming contínuo pode atualizar resultados à medida que os eventos avançam. Essas estratégias possuem compromissos diferentes de custo, latência, consistência e manutenção. Um relatório executivo com fechamento diário talvez não se beneficie de processamento por segundo. Já um acompanhamento operacional de anomalias pode exigir intervalos curtos e tolerância explícita a dados tardios. A arquitetura deve começar pela decisão que será tomada e pelo atraso máximo aceitável, não pela vontade de utilizar determinada tecnologia.
A comparação deve considerar o comportamento das fontes e dos consumidores. Se o ERP só publica transações confirmadas após rotina de fechamento, um stream de notificações não representa faturamento oficial antes desse processamento. Um evento de manutenção pode indicar alteração no CMMS, mas sua consequência física depende de outros registros. A solução pode combinar streaming para informação operacional provisória e batch para reconciliação oficial. Essa arquitetura híbrida preserva rapidez sem ocultar as diferenças entre percepção do evento e consolidação de negócio. Cada modo precisa ter estados e critérios de publicação documentados.
Eventos de domínio e contratos de mensagens
Um evento deve indicar ocorrência, identificador, origem, versão e contexto temporal suficiente para o consumidor interpretá-lo. Um envelope padronizado, como CloudEvents, oferece convenções para metadados, mas não define o significado de pedido aprovado ou equipamento disponível. O Data Contract estabelece o que disparou o evento, como diferenciar atualização de nova ocorrência e quais campos são obrigatórios. Quando o produtor muda o contrato, é necessário avaliar consumidores e políticas de compatibilidade. Uma mensagem estruturalmente válida pode representar evento de negócio incorreto se a classificação ou o estado foram alterados.
A plataforma precisa estabelecer se a fonte envia fatos imutáveis ou snapshots de estado atual. Uma alteração de cadastro pode ter várias versões; receber a mais recente antes da anterior não deve produzir regressão indevida do estado. O consumidor precisa de identidade e versão confiáveis. Os contratos também devem informar política para mensagens canceladas, sem correspondência ou recebidas após período esperado. Essas condições integram o aceite, porque agregações e alertas podem ser afetados de maneira diferente por atrasos ou repetição.
Eventos capturados por plataformas diferentes só podem ser utilizados em análises coerentes quando contratos definem origem, identidade, timestamps e comportamento de falha. A integração sustenta a atualização sem confundir o transporte contínuo com a qualidade do resultado.
Arquitetura de streaming e estado
Brokers, tópicos e partições
Um Broker organiza transporte e retenção de eventos conforme capacidades implementadas. Apache Kafka, por exemplo, utiliza tópicos e partições para distribuir registros e apoiar processamento por grupos de consumidores. O particionamento pode preservar ordem dentro da partição segundo suas garantias, mas não deve ser interpretado como ordem global de todos os eventos. A escolha da chave de partição influencia paralelismo, carga e capacidade de reunir eventos da mesma entidade. Uma chave baseada apenas em origem pode criar partições desequilibradas; uma chave aleatória pode dificultar reconstruir sequência de uma entidade.
O dimensionamento considera taxa de eventos, tamanho, retenção, número de consumidores, réplica e recuperação de backlog. Brokers duráveis não eliminam necessidade de monitorar offsets, atraso e integridade da publicação. A arquitetura precisa declarar política de expansão e como consumidores reagirão quando partições mudarem. A escolha também depende de segurança, operação, custo e experiência da equipe. Um sistema com poucas fontes pode não justificar uma plataforma distribuída complexa. A adequação deve ser demonstrada em carga representativa, inclusive reconexão de muitos dispositivos simultaneamente.
Processamento com estado, checkpoint e replay
Operações de streaming podem manter estado para contagem, agregação, correspondência ou detecção de padrões. Um job que calcula pessoas por intervalo precisa guardar valores das janelas e decidir quando elas podem ser consideradas fechadas. Checkpoints ajudam na recuperação do estado do processador conforme a tecnologia; retenção do stream pode permitir replay. Entretanto, recuperar processamento sem repetir efeitos de negócio exige controle sobre consumidores externos e resultados publicados. Uma garantia interna de exactly-once não assegura exatamente um efeito em ERP ou email quando esses sistemas não participam da mesma transação.
A arquitetura registra versão do código, offsets ou posição de leitura, estado e resultado produzido. Em uma falha após publicar indicador e antes de confirmar progresso, um replay pode repetir atualização. O consumidor precisa de chave de evento e política de idempotência. Quando o processo é reexecutado para corrigir regra de cálculo, os relatórios afetados devem ser identificados e, quando necessário, receber revisão. Recuperar um job não é apenas voltar ao último checkpoint: é demonstrar que as medidas após retorno correspondem à população correta.
Event time, ingestion time e processing time
Event time representa o instante do acontecimento na fonte; ingestion time, o recebimento pela plataforma; processing time, o momento em que o processador executa a operação. Esses tempos podem diferir substancialmente quando há falta de conexão, filas e reprocessamento histórico. Uma série de manutenção que ficou offline durante duas horas não deve ter todos os eventos atribuídos ao instante da reconexão se o indicador representa ocorrência física. A escolha do tempo deve ser feita por medida e segundo a confiança no relógio da fonte, não por regra universal.
Se os timestamps de origem são incorretos, pode ser necessário usar informação de recepção com ressalvas ou tratar sincronização do dispositivo. O processo precisa registrar timezone, mudanças de fuso, viradas de turno e relação com períodos financeiros ou comerciais. Uma arquitetura baseada em event time ajuda a reconstruir histórico sob replay, mas pode exigir espera para eventos atrasados. A documentação define quando uma janela é considerada completa, como eventos tardios são tratados e quais valores podem sofrer revisão. Essas escolhas influenciam diretamente a interpretação do Dashboard Operacional.
Watermarks, janelas e eventos atrasados
Como funcionam Watermarks
Watermarks sinalizam progresso estimado do tempo dos eventos em frameworks que utilizam event time. Elas ajudam a decidir quando operações de janela podem produzir resultados, considerando que mensagens podem chegar fora de ordem. Uma Watermark não prova que todos os eventos ocorreram ou foram recebidos: expressa uma política de avanço temporal definida pela origem e pelo processador. A escolha de tolerância a atraso influencia latência e correção. Aguardar mais tempo permite incorporar eventos tardios, mas atrasa o resultado; fechar cedo pode exigir revisão posterior ou rejeição de dados.
O teste deve criar eventos com timestamps conhecidos, enviá-los fora de ordem e verificar como o processador agrega cada janela. Algumas plataformas permitem lateness adicional e saídas para eventos tardios que chegaram depois do limite; a disponibilidade e o comportamento dependem da versão e da configuração. O consumidor precisa saber se o valor é preliminar, consolidado ou corrigido. Não é adequado apresentar um valor provisório como definitivo sem comunicar a política de revisão. As Watermarks devem ser monitoradas junto com a idade de dados por fonte, especialmente quando uma partição fica ociosa.
Tumbling, sliding e session windows
Tumbling windows dividem eventos em intervalos não sobrepostos; sliding windows produzem intervalos com sobreposição; session windows agrupam atividades separadas por períodos de inatividade conforme regras da plataforma. As escolhas correspondem a perguntas diferentes. Uma contagem de ocorrências por cinco minutos não equivale ao número de pessoas únicas em uma hora. Uma sessão de atividade só é útil quando a definição de início e término corresponde ao fenômeno observado. A janela precisa preservar numerador, denominador e população, evitando que registros repetidos sejam contados como ocorrências distintas.
Um indicador de fila pode requerer agregações móveis para reconhecer tendência recente, enquanto relatório de fechamento necessita de períodos fixos. Uma média baseada em amostras disponíveis pode ocultar interrupção de comunicação. A engenharia deve definir cobertura mínima, eventos de início e fim e comportamento quando um dispositivo para de transmitir. Alterações na duração da janela impactam comparabilidade histórica e precisam de versão. A validação compara resultados de referência e demonstram como cada escolha responde à decisão real, não apenas à facilidade de configurar operadores.
Ordenação, deduplicação e retenção
A entrega de eventos pode ocorrer mais de uma vez e fora de ordem, especialmente após retries e reconexões. Deduplicação precisa de identificador confiável e de janela de retenção de estado apropriada. Mensagens com mesmo timestamp não são automaticamente duplicadas; duas ocorrências diferentes podem acontecer no mesmo instante. O contrato também deve definir cancelamentos, correções e eventos que alteram o significado de outro registro. Uma regra de contagem que ignora correções pode superestimar resultados após replay.
A política de retenção do Broker deve considerar disponibilidade para consumidores e recuperação de incidentes. A retenção não equivale à preservação documental de relatórios aprovados, nem garante que todo evento antigo permanecerá disponível para sempre. Um consumidor que fica offline além do limite pode perder capacidade de reconstruir a janela. O plano de continuidade deve prever essa condição, incluindo reconciliação com fonte ou reprocessamento alternativo quando possível. Os testes devem provocar atrasos maiores que o habitual para identificar limites antes de entrar em produção.
Janelas, Watermarks e garantias de processamento dependem da finalidade da informação e do risco de atraso. Uma avaliação técnica pode definir critérios de desempenho, segurança e aceitação antes de adotar uma arquitetura de eventos.
| Decisão técnica | Questão de projeto | Evidência de aceite |
|---|---|---|
| Batch ou streaming | Latência útil e consistência da fonte | Comparação com referência |
| Chave de partição | Ordem por entidade e distribuição | Sequência sob carga e replay |
| Event time | Timestamp confiável da ocorrência | Evento atrasado no período correto |
| Watermark e janela | Atraso tolerado e revisão | Resultado após dados fora de ordem |
| Deduplicação | Identidade e tempo de retenção | Replay sem contagem duplicada |
| Recuperação | Checkpoint, estado e backlog | Queda e retorno com reconciliação |
Aplicações de Business Intelligence e limites do evento
Eventos comerciais e sistemas corporativos
Em comércio, um stream de pedido criado, aprovado, cancelado ou faturado pode oferecer indicadores operacionais de fluxo do processo. Esses eventos possuem estados e finalidade diferentes; uma conversão entre pedidos e vendas não deve considerar todo pedido como faturamento realizado. O BI precisa combinar eventos com cadastros, critérios de elegibilidade e fechamento. Uma correção retroativa pode alterar contagens anteriormente publicadas. A solução deve identificar a versão da medida e distinguir visão atual do processo de relatório gerencial fechado.
Um consumidor analítico pode atualizar rapidamente métricas de backlog, mas sua comparação com resultado financeiro depende de regras compartilhadas. O ERP conserva propriedade sobre transações e o sistema de atendimento sobre etapas que executa. Streaming facilita transporte e processamento, mas não substitui integração semântica. Quando o evento apresenta somente mudança de status, pode ser necessário consultar informação complementar por interface autorizada. A arquitetura não deve transformar ausência de evento numa conclusão sobre resultado comercial.
Telemetria, alarmes e manutenção
Dispositivos IoT e sistemas de supervisão podem emitir medições e eventos de alarme. A análise pode correlacionar comportamento de ativos a registros de manutenção, preservando timestamp, unidade de engenharia, identificação e qualidade da medição. Um alarme não é automaticamente falha física confirmada, e uma ordem de manutenção encerrada não demonstra que o sensor voltou a medir. O Data Stream deve manter essas diferenças para evitar conclusões erradas sobre disponibilidade. A detecção de anomalia depende de baseline e confirmação de que os dados são representativos.
Uma desconexão pode gerar retransmissão de mensagens acumuladas. Os indicadores devem utilizar event time quando a origem é confiável e distinguir séries com lacunas de séries com valores zero. Ao relacionar o stream com CMMS ou Data Historian, a arquitetura precisa reconhecer ritmos distintos de atualização e políticas de retenção. Um alerta em tempo quase real pode iniciar investigação, mas não deve executar comando de controle em PLC ou SCADA fora de integração explicitamente aprovada. A segurança TI/OT é requisito de projeto.
Vídeo, controle de acesso e centros de operações
Plataformas de VMS e controle de acesso podem produzir eventos que ajudam a compreender uso de instalações, fluxo e resposta a ocorrências. A aplicação em Business Intelligence exige preservar origem, classificação, limitações e finalidade. Uma detecção analítica de vídeo pode ter falso positivo; uma passagem de credencial não representa necessariamente pessoa distinta. Agregações precisam reconhecer incertezas e autorizações aplicáveis. A interface analítica não substitui procedimentos de segurança, operadores ou sistemas de controle.
Em centros de operações, streaming pode apoiar filas e indicadores de eventos, mas o desenho precisa distinguir evento observado, caso validado e ação executada. Uma rajada de mensagens pode exigir agrupamento ou supressão de duplicados sem perder evidências importantes. O processo deve registrar qual regra transformou eventos em indicador ou alerta. Se a fonte fica indisponível, o painel precisa indicar lacuna. A capacidade de reagir rapidamente não significa que todas as informações foram conciliadas ou que uma ocorrência foi confirmada.
Segurança, desempenho e aceite
Controle de acesso, privacidade e responsabilidade
Um fluxo contínuo pode ampliar velocidade e alcance da divulgação de dados sensíveis. Contratos devem estabelecer quais produtores podem publicar, quais consumidores podem subscrever, classificação, minimização e retenção. Conta de serviço utilizada para ingestão não deveria permitir alterar operações de origem. Logs e mensagens podem conter informações pessoais; a proteção precisa alcançar tópicos, estados de processamento, checkpoints e arquivos temporários. Quando há dados pessoais, finalidade e tratamento devem atender a responsabilidades legais aplicáveis. Uma plataforma de streaming não assegura conformidade automaticamente.
Em ambientes industriais, obter telemetria para análise não autoriza comando físico. As interfaces devem respeitar fronteiras TI/OT, credenciais e requisitos de continuidade. O controle por tópico pode ser insuficiente quando mensagens contêm informações de unidades diferentes e consumidores devem visualizar apenas subconjuntos. A arquitetura precisa prever separação adequada de dados e testar vazamento por exportações e interfaces de consumo. Uma alteração de contrato deve acionar análise de impacto e revisão de permissões antes de ampliar o público dos eventos.
Throughput, backlog e modos degradados
O dimensionamento considera eventos por segundo, tamanho, partições, consumidores, retenção e estado mantido pelo processador. Uma plataforma capaz de processar carga média pode apresentar atraso durante reconexão de muitos dispositivos ou recuperação de período offline. O ensaio deve medir throughput, lag, atraso em Watermarks e consumo de memória, incluindo eventos fora de ordem. Aumentar paralelismo nem sempre resolve desequilíbrio de partições ou consultas lentas a sistemas externos. É necessário definir níveis de serviço por finalidade, não somente pela capacidade nominal do Broker.
Quando há backlog, o dashboard pode continuar mostrando números sem atualização efetiva. O estado degradado precisa ser comunicado, distinguindo ausência de dado de operação normal. O runbook define recuperação, limite de retenção e quando bloquear ou revisar indicadores. Uma falha no destino não deve provocar retransmissões ilimitadas que prejudicam o produtor. Backoff e filas de rejeição podem ser apropriados conforme arquitetura. O aceite precisa demonstrar recuperação com integridade e também o comportamento quando não é possível recuperar eventos perdidos na origem.
Plano de homologação e documentação
Uma validação técnica seleciona eventos conhecidos e simula duplicação, desordem, atraso, falha de Broker, perda de conexão e alteração de schema. Cada teste especifica entrada, versão, resultado esperado, limiar e responsável. A reconciliação compara contagem e medidas por população e período. A equipe deve demonstrar como reprocessar dados sob novo código sem misturar séries de versões distintas. Um relatório concluído antes da chegada de evento tardio pode exigir revisão identificada, dependendo de criticidade e uso.
Se alarmes e indicadores se multiplicam sem apoiar decisões, o problema pode estar no tratamento operacional das ocorrências. O diagnóstico dos processos permite relacionar dados capturados, responsáveis e ações, preservando o valor analítico do streaming.
A entrega inclui contratos de evento, diagrama de fluxos, chaves de partição, estratégia de timestamp, Watermarks, retenção, política de deduplicação, segurança, Quality Gates e runbooks. O teste de operação assistida deve provar que equipe diferente consegue diagnosticar atraso, identificar consumidor afetado e recuperar processamento. A documentação também registra o custo e o impacto de aumentar a frequência de atualização. O valor de Data Streaming está na capacidade de oferecer informação mais oportuna com interpretação correta e continuidade, não no número de mensagens processadas.
O Data Pipeline apresenta os controles gerais de execução. IoT Analytics e Dashboard Operacional aprofundam o aproveitamento de informações capturadas, sem confundir a fonte com a solução analítica.
Ensaios de eventos tardios, estado e recuperação
Para testar Data Streaming, selecione uma série de eventos de atendimento que inclua abertura, encaminhamento e encerramento de um caso. Cada evento precisa conservar identidade, versão, timestamp de ocorrência e fonte. O primeiro processamento entrega mensagens em ordem e calcula quantidade de casos abertos por janela de referência. Em seguida, a equipe altera a ordem de envio, duplica uma mensagem e atrasa o fechamento além do limite habitual. A solução deve demonstrar tratamento de Watermark, janela e deduplicação conforme contrato. O resultado esperado não é simplesmente a mesma contagem em todos os instantes: pode existir um número provisório, seguido de revisão quando chegam eventos tardios. O dashboard precisa expor qual versão está disponível e quais diferenças se devem à política de temporalidade.
Um ensaio de telemetria interrompe o gateway durante parte da janela e transmite em lote as medições acumuladas após reconexão. Caso os timestamps da origem sejam confiáveis, event time permite atribuir as amostras aos intervalos corretos, em vez de contabilizá-las todas no instante de chegada. O teste deve avaliar também sensores cujo relógio ficou desajustado. A plataforma não pode assumir tempo físico válido apenas porque o evento possui timestamp. A qualidade da medição e a cobertura por janela precisam ser verificadas e apresentadas aos consumidores. Uma contagem zero durante a falha não é evidência de ausência de ocorrências. Esse cuidado é particularmente relevante em manutenção, instalações e sistemas de monitoramento.
O terceiro teste provoca falha do processador depois de atualizar um estado agregado, mas antes de registrar confirmação de progresso. A equipe restaura checkpoint, executa replay e compara o resultado final com a amostra de referência. A garantia de exactly-once do framework, se configurada e suportada para aquele fluxo, não substitui idempotência de chamadas a serviços externos ou publicação de documentos. O consumidor deve reconhecer identificadores e versões para evitar efeitos repetidos. Caso a retenção do stream seja menor que o período de indisponibilidade, a solução precisa demonstrar método alternativo de reconciliação ou declarar que determinadas janelas não podem ser recuperadas. A auditoria registra essa limitação como risco, não como ocorrência inexistente.
O último ensaio testa carga de pico, consumidores lentos e alteração de contrato de evento. A arquitetura mede lag, atraso de Watermarks, throughput e recursos empregados para manter o estado. A equipe verifica se um schema novo mantém compatibilidade e se a alteração do significado de um status precisa de aprovação do Data Owner. Uma mudança sintaticamente válida pode tornar o indicador incorreto, mesmo quando o fluxo continua sendo processado. O pacote final contém diagrama da cadeia, contratos, regras de janela e lateness, limites de retenção, testes de autorização e procedimento de recuperação. Esses elementos permitem avaliar se o streaming oferece informação mais oportuna sem sacrificar rastreabilidade e confiabilidade do Business Intelligence.
Também é necessário diferenciar a qualidade do transporte da utilidade de um alerta produzido pelo stream. Um fluxo sem atraso pode amplificar eventos irrelevantes se a regra de agregação não distingue repetição, manutenção programada e ocorrência confirmada. A equipe precisa avaliar taxa de alertas úteis, procedimentos de escalonamento e impacto de falsos positivos, sem transferir diretamente uma detecção de vídeo ou sensor para uma decisão contratual. O Business Intelligence utiliza os registros para produzir contexto e comparação, não para substituir a avaliação operacional. O desenho deve preservar a capacidade de investigar eventos originais quando uma regra analítica for ajustada.
Na contratação, as garantias técnicas precisam ser especificadas por etapa. Retenção do Broker, consistência do estado, atualização do consumidor e recuperação do histórico são requisitos distintos. É possível que a plataforma restaure seu estado interno, mas um arquivo exportado antes da correção continue com valor antigo. O processo deve reconhecer quais documentos e dashboards necessitam revisão e quem pode aprová-la. O aceite também precisa incluir segurança, segregação de dados, continuidade e documentação para operação assistida. A complexidade de streaming só se justifica quando a antecipação da informação beneficia decisões reais e quando o custo de manter essas garantias é aceitável.
Considerações finais
Data Streaming permite aproximar dados e eventos do momento da decisão, mas o processamento contínuo não elimina necessidade de qualidade, semântica e governança. Uma arquitetura deve escolher event time ou outro referencial de acordo com a confiabilidade das fontes, definir janelas e Watermarks e demonstrar comportamento com eventos tardios, repetidos e fora de ordem. A retenção, o estado do processamento e a recuperação precisam ser especificados com resultados observáveis, evitando confundir garantias internas da plataforma com o efeito final em sistemas externos.
O aceite deve comprovar informação válida durante operação normal, degradada e após falhas, com indicadores de atualização que permitam reconhecer lacunas. Streaming pode coexistir com batch para conciliação oficial, e seus benefícios dependem da latência exigida pelo negócio. A organização deve contratar e avaliar os componentes pela capacidade de sustentar decisões reproduzíveis e seguras, e não pela adoção de uma tecnologia de eventos específica.
Referências técnicas
[1] APACHE SOFTWARE FOUNDATION. Apache Flink: Timely Stream Processing. Documentação do projeto. Disponível em: https://nightlies.apache.org/flink/flink-docs-master/docs/concepts/time/
[2] CONFLUENT. Kafka Streams: Processing Guarantees. Documentação. Disponível em: https://docs.confluent.io/platform/current/streams/concepts.html
[3] CONFLUENT. Event-Time Processing. Developer Patterns. Disponível em: https://developer.confluent.io/patterns/stream-processing/event-time-processing/
[4] CLOUD NATIVE COMPUTING FOUNDATION. CloudEvents Specification. Disponível em: https://github.com/cloudevents/spec
Perguntas frequentes
É o processamento contínuo de registros e eventos para disponibilizar análises com latência adequada à decisão.
Não necessariamente. Processamento periódico continua útil para conciliação e fechamento.
É o momento em que o evento ocorreu segundo fonte, distinto de recebimento e processamento.
Sinal de progresso temporal utilizado por certos processadores para controlar janelas e eventos atrasados.
Tumbling usa intervalos sem sobreposição; sliding permite intervalos sobrepostos.
Agrupa eventos em períodos de atividade separados por inatividade, conforme regra configurada.
Não automaticamente. Garantias de processamento dependem da configuração e dos efeitos sobre consumidores externos.
Sim. Retries e recuperação exigem identidade de evento e deduplicação ou idempotência.
Com regra de tempo, Watermarks, política de lateness e eventual revisão dos indicadores.
Acúmulo de eventos ainda não processados, que deve ser monitorado e recuperado sob limites.
Quando informações de eventos e operação precisam apoiar decisões em janelas curtas com integridade demonstrável.
Desordem, duplicação, atrasos, segurança, falha de Broker, replay, carga e reconciliação.
