Gestione dei database di micro-servizi?

In alcuni casi, i microservizi prevedono una penalizzazione delle prestazioni, il che è compensato da una migliore scalabilità. Può sembrare un paradosso, ma a volte è necessario rallentare una singola operazione per rendere il sistema più scalabile. Nel tuo caso, una migliore scalabilità significa che non puoi gestire modifiche di stato complesse tra più tabelle in una singola istruzione SQL. Quindi, sta a te decidere quale sia più importante: scalabilità o prestazioni a singola operazione. I microservizi non sono un proiettile d'argento e hanno senso in alcuni casi e non in altri.

Una cosa che ti consiglierei di non fare, tuttavia, è la soluzione di scrivere "microservizi" che operano su un database condiviso. Questo ti darebbe il peggio di entrambi i mondi: il database condiviso limita la tua scalabilità in modo da non ottenere uno dei principali vantaggi che i microservizi normalmente offrono mentre il tuo codice suddiviso in più applicazioni separate aggiunge tutti i costi di programmazione, implementazione e manutenzione del mondo dei microservizi. Si noti che in tali situazioni tutte le applicazioni dipendono dallo stesso database, pertanto qualsiasi modifica al DB è molto più difficile da implementare e distribuire rispetto a un'applicazione monolitica. Quindi ottieni la maggior parte dei lati negativi di entrambi i mondi.

Il motivo per cui spesso si dispone di un database per ogni micro-servizio, è per separare ogni parte del sistema. Se si memorizza tutto in un database, si avrà (come menzionato da Michal Kosmulski) una certa scalabilità. Ma ancora più importante, ogni microservizio potrebbe essere meglio con qualche altra forma di archiviazione. Alcuni dei tuoi micro-servizi potrebbero essere migliori con un database relazionale - altri potrebbero essere migliori con alcuni database NoSQL.

Avere un archivio dati separato per ogni micro-servizio, significa che puoi scegliere la soluzione migliore per ogni servizio. Non devi cercare di adattare tutto in un unico grande RDBMS.

Un altro vantaggio è che nessun altro servizio (magari codificato e gestito da un altro team) ha il "bisogno" di guardare direttamente nel tuo database, invece di chiamare il tuo servizio - semplicemente non hanno accesso ad esso. Quindi DEVONO utilizzare il tuo servizio, il che significa che puoi controllare direttamente ogni chiamata e cambiare i dati.