Le pipeline di eventi in tempo reale si interrompono in uno di due punti: gli eventi non attraversano lo strato di ingestione in modo affidabile oppure non diventano mai query veloci nella piattaforma. Si tratta di problemi distinti che richiedono strumenti diversi, e risolvere solo uno di questi è il motivo per cui i team finiscono con stack costosi e fragili.

Senza una backbone di streaming durevole, i produttori e i consumatori di dati distribuiti finiscono per essere strettamente interconnessi. I produttori sono le applicazioni che generano e inviano eventi ai topic Kafka, mentre i consumatori sono i servizi che leggono quegli eventi. I produttori scrivono direttamente su code, database o servizi personalizzati e, quando un consumatore si blocca o rallenta, il produttore si blocca o inizia a perdere eventi.

Inoltre, PostgreSQL e database OLTP Public Cloud simili sono progettati per operazioni a livello di riga: inserimenti, aggiornamenti, eliminazioni. Non sono progettati per scansionare miliardi di righe, effettuare aggregazioni su più dimensioni o aggiornare dashboard ogni minuto. Man mano che il volume degli eventi cresce, le query che prima restituivano risultati in 200 ms iniziano a richiedere alcuni secondi, poi decine di secondi e infine minuti. Il sistema diventa un collo di bottiglia per le decisioni di prodotto.

Quando la pipeline dell'app è lenta o inaffidabile, le conseguenze sono misurabili. I tempi di risposta per il rilevamento delle frodi si allungano da secondi a minuti, il che in FinTech si traduce direttamente in perdite finanziarie e rischi per la reputazione. I cicli di reporting lenti bloccano le decisioni di prodotto e costringono i team a fare affidamento su snapshot che sono già obsoleti nel momento in cui vengono esaminati. Per ovviare al problema, i team iniziano a correggere lo stack. Processi ETL personalizzati, code di messaggi assemblate manualmente e viste di reporting si accumulano in una pipeline ad-hoc che deve essere mantenuta manualmente. Il costo reale non è solo la latenza immediata. È il rallentamento operativo, il debito tecnico e il fatto che il team non possa iterare sulle funzionalità in tempo reale perché è impegnato a mantenere in vita la pipeline esistente.