Sono un principiante dell'architettura dei dati basata su eventi che usa Kafka / Kinesis come fulcro (attualmente Kinesis) e ho alcune domande su come costruire un'API WebSocket su tale struttura. Il mio caso d'uso specifico è che ho circa 4 diversi flussi di dati in arrivo in Kinesis, li combino in un "flusso aggregato" dopo aver eseguito qualche elaborazione, e poi memorizzo il risultato di tale flusso in un DB distribuito per scopi storici. Viene anche emesso come un altro stream Kinesis per altri utenti.
Il mio obiettivo è che voglio che questo flusso finale di dati sia consegnato a un client Web in tempo reale e che il client sia in grado di vedere i dati storici del flusso. Ho un paio di domande su come dovrei progettare un sistema del genere.
- L'API dovrebbe consumare direttamente il flusso Kinesis e inoltrare i messaggi al client? O è meglio avere un middle layer che si trova tra lo stream Kinesis e il client API per gestire alcuni stati.
- Qual è l'approccio consigliato per gestire il replay? Supponiamo che un client perda la connessione allo stream e ritorni 5 minuti dopo. Come posso tenere traccia di dove il cliente si è interrotto in modo da poter riprodurre quegli eventi e poi recuperare il "capo" del flusso?
- Basandosi su 2., dovrei avere una sorta di meccanismo di checkpoint sullo stream dove qualsiasi cosa prima del checkpoint si troverebbe nel database distribuito e dopo tutto quello che sarebbe stato riprodotto?
- Dovrei persino provare a implementare una funzionalità di replay e piuttosto a scrivere in modo aggressivo sul DB distribuito in modo che il DB distribuito abbia una registrazione costante dello stato vero? Allora forse sul client si potrebbe fare un semplice sondaggio del database. Credo che questo sia un po 'imbroglio però.
Grazie per il tuo aiuto!