I microservizi forniscono un'API ai loro dati. I servizi stessi possono accedere direttamente ai propri dati, non c'è bisogno di aggiungere un'astrazione addizionale in mezzo. In questo senso, il database è un dettaglio di implementazione di un microservizio.
Se vuoi esporre un'API diversa dall'offerta dei microservizi, sarebbe un servizio separato o una specie di gateway API, ma questa API non dovrebbe conoscere direttamente i database.
In ogni caso, costruisci solo ciò di cui hai bisogno. Puoi rifattorizzare la struttura interna in un secondo momento se si è dimostrata inadatta. Ad esempio, se si distribuiscono i microservizi in locale per i client, è possibile che si desideri interfacciare con qualsiasi sistema di database che il client utilizza già. Quindi, un qualche tipo di servizio di persistenza per astrarre qualsiasi differenza potrebbe avere senso.
Si noti che "server" può significare sia "un software che risponde alle richieste" sia "un componente hardware che si trova in un rack". Ogni microservizio dovrebbe essere il proprio server software, sebbene possa condividere l'hardware. Tuttavia, i database più grandi hanno requisiti hardware univoci, nel qual caso non si dovrebbero eseguire altri servizi sull'hardware del database. In un'impostazione cloud, tutto ciò sarebbe comunque sottratto, soprattutto quando si utilizza un meccanismo di orchestrazione dei contenitori.