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

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

А в реальности удобнее дать человеку зарегаться только по email и паролю. А потом просто когда он пойдёт что-то делать через неделю вывести плашку "Чтобы выглядеть красиво в комментариях заполните имя". И потом через месяц "Чтобы вывести деньги заполните реквизиты".

Так что гарантия присутствия у юзера профиля и реквизитов мало кому действительно нужна.

Ну все что вы рассказали выглядит ужасно перемудренно, разве консистентность не достигается меседж брокерами? Какая транзакционность, это уже из разряда баз данных, а если это из разряда базы данных, тогда может стоит и использовать эти самые базы данных, а не выдумывать себе проблем?)))
Опять же, я лишь высказал свое наблюдение со стороны, так что если что не обижайтесь)))

ок, спасибо)

по поводу транзакционности, это внутренняя кухня бд до тех пор пока эта бд одна и есть только бд, но есть и вариант с несколькими экземплярами или другими сервисами тогда нужна уже "транзакция транзакций" и тут то и появляются саги,  двухфазные коммиты и прочая кухня очень похожая на внутренности субд

Вам не кажется вот так со стороны если отойти, что возможно в архитектуре изначально уже что-то пошло не так, если у вас появились “транзакции транзакций”? Если прямое определение транзакции уже “Транзакция может быть выполнена либо целиком и успешно, соблюдая целостность данных и независимо от параллельно идущих других транзакций, либо не выполнена вообще, и тогда она не должна произвести никакого эффекта.” А у вас получается может настать момент, когда транзакция полностью выполнилась, но теперь ее полностью нужно откатить… Так и до рекурсии недалеко…

https://www.reddit.com/r/devops/comments/myzrhh/why_are_we_faking_microservices/ недавно обсуждение забавное было)

как раз по обсуждению выше. нафиг вам микросервисы изначально сдались то

да, так и получается и я понимаю что я в шаге от того чтобы сделать дичь собираю инфу как этого избежать

спасибо большое)

саги изначально это лишь механизм распределенных транзакций. Распределенные транзакции да это сложно. Как не делать распределенных транзакций - не делать распределенный стэйт.

Вообще стоит задаться вопросом зачем вы влазили в микросервисы (микросервисы как бы подразумевают распределенный стэйт).

дичь обычно происходит из:

- кривые границы сервисов
- один человек или команда пилит все сервисы - в этом ключе просто не проявляется основная идея information hiding. Без этого толку от микросервисов ноль, одни убытки.

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

там тебе всякие event storming-и с их этим process modeling помогут. Для саг можно просто юзать готовые штуки (dapr и их экторы) тогда сложность будет именно на уровне домена.

Ключевое - микросервисы это с большего про структуру коммуникаций в организации, всякие эти teams topologies и т.д. Есть пара тройка юзкейсов связанных с change management где микросервисы могут помочь даже при наличии маленькой команды но опять же как последнее средство

у Alberto Brandolini пример был в его книге по event storming.

Бизнес мол почти всегда действует через eventual consistency. Захотели вы съесть чего в парке, видите вы хотдоги продают. Вот у нас уже есть транзакция - вы ему деньги, он вам хотдог. Только между этим есть еще время. вы не сможете провести обмен атомарно. Более того, вы можете передумать пока хотдог готовится, потому деньги вперед. Чел который готовит вам хотдог может сбежать с вашими деньгами. Вы можете лишь надеяться что те $2 которые вы отдали не дадут достаточной мотивации ему сбежать.

В итоге у нас есть момент времени когда денег у нас нет, хотдога тоже. Состояние элементов системы в целом консистентно, но мы все еще голодны.

Потому вместо того что бы думать о распределенных транзакциях лучше представлять операции в виде процессов. Мол "я сделал вот это, вот то, и если вот там то, то мы вот так".

Так и вижу как продавец хотдогов убегает с твоими 2$ оставляя тележку, хавку и все все все

особенно когда в системе есть штуки типа страйпа, отправки почты, нотификаций и прочих сторонних сервисов, да и чо далеко ходить - отправки сообщения в кафку/кролика. то о "транзакциях" слышать забавно)

слово не воробей, вылетит - не поймаешь! 😅

Так и тут))

ну вот банальная вещь - закоммитил в базу и отправил в очередь. что может пойти не так?😃

а потом всякие outbox паттерны делают

Какой же трындец… Не, я знал, что микросервисы это ветряные мельницы, но что бы на столько… Сейчас глянул паттерн, который вы сказали и ужаснулся 🤦