TL; DR: Зависит от сценария и от того, что будет делать каждая служба
Хотя на этот вопрос нет однозначного ответа, поскольку это действительно зависит от ваших потребностей и от того, что каждый служба должна делать, вы можете придумать общую отправную точку (при условии, что вам не нужно сохранять существующий тип базы данных).
Предположим, у вас есть монолитное c приложение для электронной коммерции, и вы хотите разделить это приложение на более мелкие сервисы, каждый со своей базой данных. Подход, который вы можете использовать, заключается в создании некоторых сервисов, которые обрабатывают некоторые части веб-сайта: например, у вас может быть один сервис, который обрабатывает аутентификацию пользователей, один для заказов, один для продуктов, один для счетов и так далее ...
Теперь у каждой службы будет своя собственная база данных, и вот еще один вопрос: какая база данных должна быть у конкретной службы c? Поскольку одним из преимуществ архитектуры такого типа является то, что у каждого сервиса может быть своя собственная база данных, поэтому, например, сервис продуктов может иметь нереляционную базу данных, такую как MongoDB, поскольку все, что он делает, - это получение подробных сведений о продуктах, поэтому Вам не нужно управлять какими-либо отношениями.
Служба заказов, с другой стороны, может иметь реляционную базу данных, поскольку вы хотите сохранить связь между заказом и счетом для этого заказа. Но подождите, счета обрабатываются службой счетов, так как же вы можете сохранить связь между этими двумя без совместного использования базы данных? Что ж, это одна из «проблем» этого подхода: вы должны сохранять независимость сервисов, а также позволять им общаться друг с другом. Как мы можем это сделать? Здесь также нет четкого ответа ... Один из подходов может состоять в том, чтобы просто передать все детали счетов-фактур в службу заказов, или вы можете просто передать идентификатор счета-фактуры при сохранении заказа, а затем получить счет-фактуру с помощью вызова API в или вы можете передать всю необходимую информацию, необходимую для выставления счета, конечной точке API в службе заказов, которая хранит эти данные в определенной таблице c в базе данных (поскольку в большинстве случаев вам не нужны весь фактический объект), et c ... Возможности бесконечны ...