Более развитые хранилища событий используют отслеживание транзакционного журнала
Хороший способ организации бизнес-логики сервиса — ее разделение на агрегаты по принципу DDD. Агрегаты делают доменную модель более модульной, исключают возможность применения объектных ссылок между сервисами и гарантируют, что каждая ACID-транзакция выполняется в рамках одного сервиса.
дискуссиях такого рода мнения слишком расходятся. Для этого феномена даже есть специальный термин — Suck/Rock Dichotomy (http://nealford.com/memeagora/2009/08/05/suck-rock-dichotomy.html, Нил Форд (Neal Ford)), который иллюстрирует ситуацию, когда в мире программного обеспечения все либо очень хорошо, либо очень плохо. Такая аргументация имеет следующий вид: если вы сделаете X, произойдет катастрофа, поэтому вы должны сделать Y. Примером может служить противостояние между синхронным и реактивным программированием, объектно-ориентированным и функциональным подходами, Java и JavaScript, REST и обменом сообщениями. В реальности, естественно, все немного сложнее. У каждой технологии есть недостатки и ограничения, ее приверженцы их часто игнорируют. В итоге переход на ту или иную технологию обычно происходит в соответствии с циклом зрелости (https://ru.wikipedia.org/wiki/Gartner#Цикл_хайпа), состоящим из пяти стадий, включая пик чрезмерных ожиданий (мы нашли панацею), избавление от иллюзий (это никуда не годится) и плато продуктивности (теперь мы понимаем все плюсы и минусы и знаем, когда это лучше применять).
Микросервисы в этом смысле не исключение. Подходит ли данная архитектура для вашего приложения, зависит от множества факторов. Следовательно, нельзя воспринимать их как решение на все случаи жизни, равно как и не стоит полностью от них отказываться. Как часто бывает, нужно учитывать конкретную ситуацию.