Os pipelines de eventos em tempo real falham em uma de duas situações: ou os eventos não conseguem passar pela camada de carregamento de forma fiável, ou nunca se transformam em consultas rápidas na plataforma. Estes são problemas distintos que exigem ferramentas diferentes, e resolver apenas um deles é o que leva as equipas a acabar com estruturas frágeis e dispendiosas.

Sem uma base de streaming duradoura, os produtores e consumidores de dados distribuídos ficam fortemente interligados. Os produtores são as aplicações que geram e enviam eventos para tópicos do Kafka, enquanto os consumidores são os serviços que leem esses eventos. Os produtores escrevem diretamente em filas, bases de dados ou serviços personalizados e, quando um consumidor fica inativo ou apresenta atrasos, o produtor bloqueia ou começa a descartar eventos.

Além disso, o PostgreSQL e outras bases de dados OLTP semelhantes na Cloud Pública foram concebidos para operações ao nível da linha: inserções, atualizações, eliminações. Não foram concebidos para analisar milhares de milhões de linhas, agregar dados em várias dimensões ou atualizar painéis de controlo a cada minuto. À medida que o volume de eventos aumenta, as consultas que costumavam devolver resultados em 200 ms começam a demorar segundos, depois dezenas de segundos, e depois minutos. O sistema torna-se um congestionamento para as decisões de produto.

Quando o pipeline da aplicação é lento ou pouco fiável, as consequências são mensuráveis. Os tempos de resposta da deteção de fraudes variam entre segundos e minutos, o que, no setor da FinTech, se traduz diretamente em perdas financeiras e riscos para a reputação. Os ciclos de elaboração de relatórios lentos impedem a tomada de decisões sobre os produtos e obrigam as equipas a basear-se em dados pontuais que já estão desatualizados na altura em que são analisados. Para compensar, as equipas começam a corrigir a estrutura. As tarefas de ETL personalizados, filas de mensagens criadas manualmente e vistas de relatórios acumulam-se num pipeline ad-hoc que tem de ser mantido manualmente. O custo real não é apenas a latência imediata. É o desgaste operacional, a dívida técnica e o facto de a equipa não conseguir desenvolver funcionalidades em tempo real, uma vez que está ocupada a manter o pipeline existente em funcionamento.