Паттерны микросервисной архитектуры - Лекция 1 - Transactional Outbox

[jarogor]

В варианте «и такое бывает» проблема та же, если брокер сообщений пуш типа, у него задача сделать два пуша, а между ними может произойти обрыв. Но если это пул тип, то есть он пассивен, данные в него пришли один раз, а забирать можно много раз, то один раз заберёт консьюмер и положит в базу, а другой раз заберёт сервис B. Но там у стрелочек направление поменять и название, это больше не события. Минус тут в том, что порядок не гарантирован.

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

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

[wvvwwwvvw]

1:28 эээ, а где найти упомянутый доклад по CQRS? Тут на канале только 12 лекций по async/multithreaded, nbomber и этот видос..

[grant-ilum]

Поделитесь, плиз, ссылкой на доклад по gRPC, о котором в начале видео говорится (2:54)

[tertiumorganum]

Не полное либо на дурака описание первого варианта, коли все может упасть то слишком просто