Микросервисы это не про транзакции, микросервисы это про разбиение функционала на отдельные сервисы котором НЕ нужно общаться между собой атомарно/консистентно/транзакционно/без race-conditions. Если у вас одному микросервису вдруг нужно прочитать и обновить данные другого микросервиса атомарно то это значит что вы неправильно спроектировали микросервисы.
Вообще микросервисы подходят далеко не под каждый проект. Если у вас функционал очень связанный (фичи требуют чтения и обновления многих связанных данных) то это значит что микросервисный подход вам не подходит. В этом случае либо делайте монолит и пишите логику общаясь с бд через транзакции либо разбивайте на отдельные серверы/сервисы которые будут читать и менять данные в общей базе. При этом всю работу с бд не забудьте заврапить в транзакции с serializable-уровнем изоляции транзакций а то в mysql и postgres транзакции по дефолту допускают race-conditions (причем заврапить в транзакции нужно не считывание отдельных записей а весь код бизнес-логики/запроса который читает, проверяет и обновляет много разных объектов)
Вот могу посоветовать хороший доклад про транзакции -
https://www.youtube.com/watch?v=5ZjhNTM8XU8Ну а если вдруг какой-нибудь postgres не умеет быстро обрабатывать транзакции с serializable-уровнем изоляции то выбросите его на свалку потому что например тарантул умеет обрабатывать больше 100 тысяч serializable-транзакций в секунду и при этом сохранять все данные на диск без риска потерять данные как в редисе (вот есть хороший доклад про его архитектуру -
https://www.youtube.com/watch?v=yrTF3qH8ey8)