Vorrei mostrare alcuni eventi in "tempo reale". Tuttavia, devo recuperare i dati da un'altra fonte. Posso richiedere gli ultimi X minuti, anche se la sorgente viene aggiornata approssimativamente ogni 5 minuti. Ciò significa che ci sarà un ritardo tra i dati più recenti recuperati e il momento in cui faccio la richiesta.
In secondo luogo, perché riceverò una serie di dati, non voglio semplicemente spegnere tutti gli eventi giù da una presa una volta che il mio fetcher l'ha recuperata: mi piacerebbe distribuire gli eventi in modo che siano entrambi accuratamente distanziati tra loro e in sincrono con le loro occorrenze originali (ad esempio, un evento viene sempre visualizzato 6 minuti dopo che è effettivamente avvenuto).
Il mio pensiero è di recuperare i dati ogni 5 minuti dalla fonte, sapendo che non otterrò i dati più recenti. I dati originali verranno quindi accodati per essere inviati al socket a 7,5 minuti dal timestamp originale, ovvero a circa 2,5 minuti da quando è stato recuperato il suo batch e al massimo 7,5 minuti da allora.
La mia domanda è questa: è questo il modo migliore per affrontare il problema? Questo problema presenta approcci standard o letteratura associata relativi alle best practice di implementazione e ai casi limite?
Sono un po 'preoccupato che la frequenza dei miei recuperi e la frequenza con cui la sorgente viene aggiornata andranno fuori sincrono, portando a punti in cui nessun dato sarà recuperato dalla fonte. Tuttavia, poiché il ritardo del socket è maggiore della frequenza di recupero, il recupero successivo dovrebbe recuperare i dati più recenti prima che la coda del socket sia vuota.
È corretto? Mi manca qualcosa?
Grazie!