Database dei microservizi per modello di servizio

Il servizio di prenotazione non ha motivi per conoscere il nome o il cognome dell'utente, né la sua età, sesso, indirizzo e-mail o numero di telefono. Ciò che il servizio di prenotazione deve sapere è il link a una determinata persona che prenota la tabella e che sarebbe l'identificatore univoco dell'utente.

Successivamente, quando è necessario visualizzare una prenotazione, con il nome e il cognome della persona associata e probabilmente il numero di telefono (per poter contattare la persona in caso di problemi), l'applicazione che visualizza queste informazioni farà due chiama a due servizi: il servizio di prenotazione e, da lì, il servizio utente (specificando l'identificativo dell'utente).

L'architettura dei microservizi non è una scusa per duplicare i dati. Se lo fai, creerai rapidamente incongruenze, che sono, data la natura distribuita, molto difficili da eliminare. Quindi archivia i riferimenti, non i dati duplicati.

Dipende da ciò che stai cercando di realizzare.

Se vuoi che la tua API di prenotazione sia autonoma e hai bisogno di accedere alle informazioni ridondanti, allora sì, dovrai archiviare tali informazioni nel database di prenotazione.

Se sei disposto a fare una chiamata API al servizio utente per ottenere tali informazioni, o cercare direttamente quelle informazioni nel database utente, allora no, non è necessario memorizzare le informazioni ridondanti nel database di prenotazione .

Il tradeoff è il solito: speed vs. Single Source of Truth. Poiché l'obiettivo di prestazione dei microservizi è la scalabilità (e non necessariamente la velocità di esecuzione grezza), non dovrebbe infastidirti tanto da passare alla singola fonte per i dati.