Un modello hared-database-per-service

Nello shared-database-per-service schema, lo stesso database è condiviso da diversi microservizi. È necessario valutare attentamente l'architettura dell'applicazione prima di adottare questo modello e assicurarsi di evitare gli hot table (tabelle singole condivise tra più microservizi). Tutte le modifiche al database devono inoltre essere compatibili con le versioni precedenti; ad esempio, gli sviluppatori possono eliminare colonne o tabelle solo se agli oggetti non fanno riferimento la versione corrente e precedente di tutti i microservizi.

Nella figura seguente, un database assicurativo è condiviso da tutti i microservizi e una policy IAM fornisce l'accesso al database. Ciò crea un accoppiamento dei tempi di sviluppo; ad esempio, una modifica nel microservizio «Vendite» deve coordinare le modifiche allo schema con il microservizio «Cliente». Questo modello non riduce le dipendenze tra i team di sviluppo e introduce l'accoppiamento in fase di esecuzione perché tutti i microservizi condividono lo stesso database. Ad esempio, le transazioni «Vendite» di lunga durata possono bloccare la tabella «Cliente» e ciò blocca le transazioni «Clienti».

Dovresti prendere in considerazione l'utilizzo di questo modello se:

• Non vuoi rifattorizzare troppo la tua base di codice esistente.

• Implementate la coerenza dei dati utilizzando transazioni che garantiscono atomicità, coerenza, isolamento e durabilità (ACID).

• Desideri mantenere e gestire un solo database.

• L'implementazione del database-per-service modello è difficile a causa delle interdipendenze tra i microservizi esistenti.

• Non vuoi riprogettare completamente il tuo livello di dati esistente.