Гранулярность микросервиса: Следует ли вообще разбивать сервис на более мелкие сервисы с общей базой данных?
Как указано в комментариях выше, это действительно зависит, как всегда.
Сохраненные данные достаточно статичны? Если это так, вы можете рассмотреть кеш только для чтения для вашей службы GET в качестве промежуточного звена между базой данных, управляемой службой POST, и службами GET.
Является ли объем данных относительно небольшим? Вы можете рассмотреть возможность использования CQRS с источником событий. Служба POST (или служба команд в архитектуре CQRS) создает и отправляет событие каждый раз, когда данные необходимо сохранить/обновить/удалить. Вместо хранения данных в собственной базе данных событие, содержащее данные, сохраняется в хранилище событий. Служба GET (или служба запросов) поддерживает собственный экземпляр базы данных и отслеживает события, передаваемые службой команд. Данные, хранящиеся службой запросов, создаются специально для варианта использования, который требует запроса данных, и заполняются каждый раз при запуске экземпляра службы запросов путем воспроизведения всех событий в хранилище событий. База данных в памяти может использоваться, когда объем данных относительно невелик. Имейте в виду, что вам необходимо принять возможную согласованность при использовании CQRS.
Вы можете принять антишаблон и разделить базу данных между службами чтения и записи. В этом случае вы также можете использовать CQRS и совместно использовать базу данных только для служб запросов.
Используйте отдельные базы данных и проверьте, может ли репликация на уровне ядра базы данных решить проблему синхронизации нескольких экземпляров GET с экземпляром POST базы данных. CDC (сбор данных об изменениях) также может быть вариантом в этих обстоятельствах для синхронизации различных баз данных для служб GET с одной из служб POST. Опять же, вы должны знать о возможной согласованности.
...
Надеюсь, это вдохновит вас на возможные подходы к решению проблемы.
Рекомендую посмотреть эти видео для лучшего погружения в вопрос: