Eсть 3 микросервиса: Authorization, Sender (имеет базу данных event store,в

которой сохраняются евенты),
Consumer (этот микросервис получается евенты по очереди от Sender и выполняет какие-то действия).

Authorization микросервис использует реверс прокси, который перенаправляет запросы или на Sender или на Consumer.

Есть сущность (сохраняется в consumer бд):
UserEntity (id, name, balance),
И событие (сохраняется в event store):
TransactionCreatedEvent (id, from, to, amount)

Когда пользователь хочет перевести деньги другому пользователю, он отправляет пост-запрос с данными на контроллер сендера, эти данные заполняются в сущность события,
затем сущность события сохраняется в event store и загоняется в очередь, для того чтобы этот евент поймал consumer.

По сути говоря не ясно когда евент в очереди дойдет до consumer, может сразу может через минуты 2 например. Тогда что делать в ситуации, когда пользователь
хочет перевести деньги больше чем у него есть на балансе, если сендер не может ждать пока евент дойдет? Получается в любом исходе сендер
после того как бросил евент в очередь кидает статус код 200, что всё хорошо, и только через какое то время выяснится что транзакция не удалась, как об этом сообщить?

Микросервисы подразумевают контролирующую надстройку над ними, которая будет мониторить коллизии и прочее. Если по простому в вашем случае вам необходимо сделать очередь персистентной, и в самом событии хранить статус, а клиент должен пинговать или иным способом(тот же веб сокет) получать этот статус, после того как ваш сендер положил событие, оно должно быть иметь статус - в процессе, а дальше уже статус выставляется в зависимости от того как отработал консюмер. ЗЫ: Микросервисы та еще дрянь, крайне сложная и дорогая, особенно если нужен ACID.

интересно

Если вы думаете что достаточно просто натыкать инстансов и связать их какимнить сервис басом, или даже просто хттп запросами и вуаля, то вас ждут разнообразные пока скрытые от вас грабли, и не все из них взрослого размера )

Это по сути распределенная транзакция, вид с боку. Там два основных шаблона поведения, это сага, и 2 pc , можно сделать гибрид. По сути,это выглядит так. Выходит событие что мы списываем деньги со счета. У нас висит глобальная транзакция, приходит событие зачисления на счёт. Транзакция ждёт пока эти два события не уведомят что они возможны, и они завершены. После этого транзакция закрывается. Но есть проблемы, например если события зачисления работало раньше, на счёте стало много шекелей. С счета списываются все шекили. Проходит эта транзакция вторая, и закрывается, а первая ещё активная. Но она не провелась, и приходит сигнал отката транзакции, и по скольку со счета списали все. То баланс уходит в минус и становится не валидным. Там много таких вещей где можно выстрелить в ногу.