На хабре есть перевод довольно интересной статьи: Распутывание микросервисов или балансировка сложности в распределенных системах.

Где наконец-то говорится, что микросервисы это не так уж хорошо и не всегда применимо. В конце статьи очень интересный список ссылок.

Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].

Что происходит? Почему так много проектов стало невозможно поддерживать, несмотря на обещание микросервисов простоты и гибкости? Или все-таки монолиты лучше?

Я вот сам трушных микросервисов ни разу не встречал. Так что бы 1 сервис — 1 бд. Обычно делали 1 ил 2 бд к которым подключались несколько сервисов.
Либо же вообще за работу с каждой бд отвечал свой сервис, а остальные уже подключались к нему.
А вся эта куча сервисов как правило была доступна фронту через какой-либо api gateway типа ocelot.

Несколько бд было только в том случае, если одна реляционная, а другая — нет.

Кто как делает?

Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.