Modo corretto per gestire il database per l'architettura backend distribuita

In teoria, ognuno dei servizi di gestione dei messaggi è già un'apologia del database.

La vera domanda è: hai separato i tuoi dati correttamente?

Se disponi di molti servizi, tutti utilizzano lo stesso database come "odore di codice". Non perché i tuoi servizi accedano direttamente al database, ma perché utilizzano lo stesso stesso database.

Ora se stanno facendo tutte le azioni del database, ad esempio aggiornando lo stato dell'ordine mentre gli eventi si verificano. Va bene, si nasconde il db dietro un servizio di ordine e si parte.

Se tutti hanno le proprie tabelle e operazioni separate, dovresti pensare a separare i dati in un database esclusivamente per quel servizio.

Come fai notare un'API centrale che nasconde i dettagli dell'implementazione del database è la soluzione più semplice e probabilmente abbastanza buona. Non mi preoccuperei troppo delle prestazioni se le query direttamente eseguono già sufficientemente.

Tuttavia, è possibile che un'API centrale diventi un collo di bottiglia. In questi casi, un approccio possibile consiste nel far sì che le modifiche dell'API centrale vengano trasmesse nel momento in cui si verificano, in un log dei messaggi e quindi riprodurre il registro dei messaggi in un altro database in ognuno dei servizi che lo consumano. Lo schema del registro messaggi è separato dallo schema del database di origine, quindi è possibile continuare a eseguire le migrazioni senza influire sulle letture. Ogni servizio richiede una propria copia del database, quindi non vi è alcun collo di bottiglia centrale. Le operazioni di scrittura devono ancora passare attraverso l'API di origine e leggere le operazioni anche nei casi in cui è necessario garantire la visualizzazione dell'ultima versione dei dati (perché questo sistema alla fine sarebbe coerente). Questo approccio introduce molta complessità, quindi vorrei evitarlo e seguire l'approccio API centrale per quanto ragionevolmente possibile.