#transactional_outbox — Public Fediverse posts

Паттерн Transactional Outbox на примере двух микросервисов на java

Всем привет! В данной статье будет описан один из возможных вариантов реализации паттерна outbox transactional. План данной статьи такой. Вначале немного теории, а потом на примере двух микросервисов будет показала реализация данного паттерна с помощью debezium и kafka. Данная статья будет полезна для новичков, которые не встречались с данным паттерном. Весь код микросервисов будет доступен по ссылкам. Но вначале немного теории. Самый главный вопрос зачем нужен данный паттерн и какую он решает задачу. Паттерн Outbox – используется в распределенных транзакциях, то есть в транзакциях, которые проходят и затрагивают несколько микровервисов, для обеспечения гарантированной доставки сообщения от одного микросервиса до другого. Данный паттерн используется там, где очень критично чтобы сообщение не потерялось, даже при сбоях в системе. Outbox паттерн получил распространение именно в микросервисной архитектуре, где нет возможности с помощью одной аннотации обеспечить транзакционность какого-то метода и возможный откат всей транзакции в рамках нескольких микросервисов. Теперь перейдем к практике. Допустим у нас имеется два микросервиса: order-servic, в котором клиент заказывает какой-то товар и bank-service, в котором происходит оплата за этот товар. Весь код микросервисов будет доступен по ссылкам. Задача в том, чтобы при заказе товара обязательно произошло списание денег за него или если денег недостаточно или возникла ошибка на стороне банка микросервис по заказам узнал об этом. Для реализации этого паттерна я буду использовать debezium и kafka.

https://habr.com/ru/articles/991934/

#java #паттерны_проектирования #outbox #outboxпаттерн #transactional_outbox #kafkaconnect #debezium

«Два стула» для данных: как мы боремся с рассинхроном в Rust-сервисе между Solana и PostgreSQL

Представьте: вы строите систему верификации дипломов. Требования простые — данные должны быть неизменяемыми (привет, блокчейн) и при этом быстро доступными для запросов (привет, PostgreSQL). Казалось бы, идеальное решение — писать в оба хранилища. Но дьявол, как всегда, кроется в деталях. Наш проект использует паттерн двойной записи (Dual-Write): Solana — гарантирует неизменность и прозрачность данных о выданных дипломах PostgreSQL (Supabase) — обеспечивает быстрые выборки и сложные запросы Звучит красиво на архитектурных диаграммах, но в production всё не так радужно. Главная проблема — частичные сбои . Транзакция в Solana прошла успешно, диплом записан в блокчейн навечно, а вот запись в PostgreSQL упала. Пользователь получил подтверждение, но половина системы о его дипломе не знает. Сегодня я покажу, как мы столкнулись с этой проблемой лицом к лицу и какие паттерны применили для её решения. Чтобы стулья не разъехались

https://habr.com/ru/articles/966194/

#rust #postgresql #solana #dualwrite #web3 #распределенные_системы #transactional_outbox #saga_pattern #консистентность_данных #архитектура

Паттерн Transactional Outbox

Какую потенциальную проблему видите в коде? Каким способом ее решить? Нужно ли вообще ее решать? Все зависит от требований к системе, конечно, поэтому принимать решения предстоит именно вам. Transactional Outbox — паттерн, который могут не знать даже Senior разработчики.

https://habr.com/ru/articles/878790/

#transactional_outbox #атомарность #согласованность #идемпотентность #транзакции #программирование #outbox

Реализация итоговой согласованности. Разбор библиотеки event-outbox

В этой статье я хотел бы рассказать об архитектурных шаблонах Transactional Outbox и Idempotent Consumer. Кроме того, я хотел бы показать собственную реализацию, содержащую интересное сочетание технологий, выходящее за рамки этих шаблонов, значительно упрощающее реализацию и эксплуатацию.

https://habr.com/ru/articles/820867/

#transactional_outbox #python3 #kafka_apache #mongodb #idempotency #я_пиарюсь