Dipende da come i tuoi consumatori elaborano i flussi.
Ogni consumatore elabora ogni tipo di evento, indipendentemente
Questo potrebbe essere un tipico flusso di registrazione: ti interessa che gli eventi accadano, ma non stai eseguendo alcuna elaborazione che deve esaminare più eventi.
In questo caso, la combinazione dei flussi ha senso: hai un singolo lettore per utente e salva gli offset dopo ogni evento o gruppo di eventi.
Un consumatore utilizza solo un singolo tipo di evento e deve eseguire alcune elaborazioni su gruppi di eventi
Questo potrebbe essere il caso in cui stai usando eventi per popolare i database downstream. Per efficienza, ti consigliamo di raccogliere più eventi per un singolo aggiornamento e potresti dover ridurre gli eventi in qualche modo (ad esempio, potresti avere più eventi per un prodotto, ma preoccuparti solo degli ultimi).
In questo caso i flussi separati hanno più senso. potresti scrivere ai tuoi utenti semplicemente per scartare eventi a cui non interessa. Tuttavia, hai una larghezza di banda fissa per letture: 5 transazioni o 2 MB al secondo per frammento. È davvero facile utilizzare questa larghezza di banda solo con i consumatori che si interessano a tutti i record; scartare i record potrebbe rendere il tuo sistema inaccettabilmente lento (o potrebbe spingerti verso implementazioni fan-out, che troverebbero ancora più complesse da gestire).
Un consumatore consuma più tipi di eventi, in lotti
Questo caso è simile al precedente, ma presuppone una sorta di interrelazione tra i tipi di evento. Ad esempio, vuoi combinare diversi tipi di eventi in una singola transazione.
In questo caso potrebbe essere opportuno combinare gli stream e fare affidamento sui dati correlati scritti insieme. In pratica, è troppo facile che i frammenti non vadano sincronizzati, il che significa che si sta effettuando il buffering dei dati e si hanno lunghe attese per salvare gli offset. In questo caso penso che Kinesis sia probabilmente la soluzione sbagliata.