Les pipelines d'événements en temps réel s’effondrent au niveau de l'un des deux points suivants : les événements ne traversent pas la couche d'ingestion de manière fiable, ou ils ne deviennent jamais des requêtes rapides dans la plateforme. Ce sont des problèmes distincts qui nécessitent des outils différents, et ne résoudre que l'un d'entre eux conduit les équipes à se retrouver avec des piles technologiques coûteuses et fragiles.

Sans une infrastructure de streaming durable, les producteurs et les consommateurs de données distribués deviennent étroitement associés. Les producteurs sont les applications qui génèrent et envoient des événements dans les topics Kafka, tandis que les consommateurs sont les services qui lisent ces événements. Les producteurs écrivent directement dans des files d'attente, des bases de données ou des services personnalisés, et lorsqu'un consommateur tombe en panne ou accuse une latence, le producteur se bloque ou commence à perdre des événements.

De plus, PostgreSQL et les bases de données Public Cloud OLTP similaires sont conçues pour des opérations au niveau des lignes : insertions, mises à jour, suppressions. Elles ne sont pas conçues pour analyser des milliards de lignes, agréger sur plusieurs dimensions ou mettre à jour des tableaux de bord chaque minute. À mesure que le volume d'événements augmente, les requêtes qui renvoyaient des résultats en 200 ms commencent à prendre des secondes, puis des dizaines de secondes, puis des minutes. Le système se transforme en goulot d'étranglement pour les décisions produit.

Lorsque le pipeline d'applications est lent ou peu fiable, les conséquences sont mesurables. Les temps de réponse de la détection de fraude passent de quelques secondes à quelques minutes, ce qui, dans la FinTech, se traduit directement par une perte financière et une atteinte à la réputation. Les cycles de reporting lents bloquent les décisions produit et forcent les équipes à s'appuyer sur des instantanés (snapshot) qui sont déjà obsolètes au moment où ils sont examinés. Pour compenser, les équipes commencent à corriger la pile. Les tâches ETL personnalisées, les files d'attente de messages assemblées manuellement et les vues de reporting s'accumulent dans un pipeline ad hoc qui doit être maintenu manuellement. Le coût réel n'est pas seulement la latence immédiate. C'est le frein opérationnel, la dette technique et le fait que l'équipe ne peut pas itérer sur des fonctionnalités en temps réel, car elle est occupée à maintenir le pipeline existant en vie.