Тема этой недели для меня Outbox Transactional, я рассказывал про него аж 3 командам 7 раз за эту неделю. Мне часто попадался этот паттерн в youtube с разных конференций, и тема мне так надоела, что я задавался вопросом, сколько этот паттерн можно уже разжевывать 🙂 а сегодня про него я пишу пост. На своем опыте убедился, что паттерн требует внимания, а именно распространения его в массы. Я не буду рассказывать как его реализовать, посмотрите на ютюбе. Подсвечу только проблему, которую он решает. Представьте у вас есть use case, в рамках которого вы пишите данные в БД и отправляете сообщение в брокер сообщений. Можно выделить три компонента: 1. приложение 2. база данных 3. брокер сообщений Каждый компонент может сломаться в процессе исполнения юз кейса. Какие состояния из этого можно получить: 1. В БД стейт изменен, в брокер сообщение отправлено - это ОК 2. В БД стейт изменен, в брокер сообщение не ушло -- это НЕ ОК, может приводить к неконсистентным данным между различными частями системы. 3. В БД стейт не изменен, в брокер сообщение ушло -- это НЕ ОК, может приводить к неконсистентным данным между различными частями системы. 4. БД стейт не изменен, в брокер сообщение не ушло - это ОК, данные не были изменены, соотвественно проблем с консистентностью не будет Какое решение? Это транзакции , но транзакция возможна только в рамках одного хранилища, которое гарантирует свойство atomicity см. ACID А одну транзакцию между разными системами не откроешь 🙂 2pc тоже не особо крутой вариант для этой задачи Здесь и вступает в игру паттерн Outbox Transactional. Суть которого заключается в том, что в рамках одной атомарной транзакции записывается стейт в БД и в эту же БД записываются сообщения, которые нужно отправить в брокер. Затем отдельным скриптом забираем сообщения из БД и шлем в брокер. Гарантии доставки : at-least once , т.е. сообщение может быть отправлено больше одного раза в брокер Считаю этот паттерн MUST HAVE для построения надежных систем, поэтому если вы ещё не знакомы с этим паттерном, рекомендую ознакомиться