Как мы четыре раза переписали Outbox

Привет! Я Ильдус Тукаев, разработчик в команде образовательной платформы Т-Банка. Мы помогаем школьникам, студентам, молодым специалистам и сотрудникам получать знания и качать свои софт и хард навыки. Основной язык у нас Go, но сегодня расскажу больше про архитектурную тему: как у нас в команде использовался паттерн Outbox и как он эволюционировал. За полтора года реализация Outbox прошла четыре итерации. По пути мы ловили VACUUM, который останавливал сервис на три часа, теряли 5% событий за полтора дня и заваливали поддержку обращениями. Расскажу, какие реализации мы пробовали, на какие грабли наступали и почему остановились на варианте, который сами же не считаем идеальным.

https://habr.com/ru/companies/tbank/articles/1039560/

#outbox #outboxпаттерн #outbox_pattern

Outbox-паттерн для мобильного мессенджера: как Telegram не теряет сообщения и почему ваш код их теряет

Это седьмая статья про инженерные решения в ONEMIX. Тема узкая, но болезненная для каждого кто делал мобильное приложение с отправкой сообщений или файлов. Сценарий с которого всё началось у меня. Пользователь в чате выбирает большое видео, нажимает отправить. Видео начинает грузиться. Пользователь нетерпеливый, прокручивает вверх посмотреть переписку, потом переходит в другой чат, потом возвращается. Что должен он увидеть? В Telegram он увидит свой видео-бабл с прогрессбаром, как и оставил. В большинстве самописных мессенджеров он увидит пустой чат без своего сообщения , потому что upload жил в state экрана, а экран размонтировался. XHR продолжал работать в фоне, файл загрузился на сервер, но результат пришёл в null, потому что setter уже не существует. Сообщение фактически отправлено, но пользователь об этом не знает. Это боль которая лечится не "правильным useState", а отдельным архитектурным слоем . Этот слой называется outbox. В этой статье разберу свою реализацию из ONEMIX, это 820 строк TypeScript которые делают то что в Telegram кажется естественным.

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

#react_native #мессенджер #optimistic_update #outbox #мобильная_разработка #архитектура #telegram #асинхронность #обработка_ошибок #retry

#ITByte: The #Outbox #Pattern is a #Design pattern that ensures that a database or external system update is delivered and published to a messaging system as a single atomic unit.

The idea of this approach is to have an "Outbox" table in the microservice's database.

https://knowledgezone.co.in/trends/browser?topic=Outbox-Pattern

[Перевод] Паттерны событийно-ориентированной архитектуры в облачном банкинге: что работает, а что ломает систему

Событийно-ориентированная архитектура часто выглядит как аккуратная схема с брокером, сервисами и красивыми стрелками между ними. В продакшене всё прозаичнее: события теряются, дублируются, приходят не по порядку, а контракты внезапно становятся долгоживущим API, который уже нельзя просто взять и переписать. В статье разбираем, как EDA ведёт себя в облачном банкинге: где она действительно помогает развязать системы и упростить аудит, а где добавляет новую сложность — от outbox/inbox и идемпотентности до границ доменных и интеграционных событий. Разобрать паттерны

https://habr.com/ru/companies/otus/articles/1031094/

#eventdriven_architecture #eda #cloudnative #банковские_системы #микросервисы #Kafka #outbox #inbox #идемпотентность

По чему Kafka недостаточно: гарантированная доставка сообщений в распределённых системах

Kafka часто воспринимается как система, гарантирующая доставку сообщений и Exactly Once Semantics. Однако в реальных распределённых системах эти гарантии заканчиваются на границе брокера. Сообщение может потеряться между записью в базу данных и публикацией события, а может быть обработано повторно при сбое сервиса. В этой статье разберём:

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

#гарантированная_доставка_сообщений #outbox #ibox #kafka #микросервисы #согласованность

Паттерн 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

Build Real Time Data Pipelines with #PostgreSQL and Apache #Nifi: #CDC via logical replication and #Outbox via table polling.

The Outbox Pattern offers simple operations and explicit control over event schemas, making it well-suited for event-driven architectures where you control the source application.

The CDC Pattern is ideal when you need the complete change history or must capture changes from applications you can't modify. However, it requires more operational overhead (compared to outbox) to manage replication slots and WAL growth.

Choose CDC (Logical Replication) when:

You need to include all changed data, including legacy applications you can't modify
Your schema changes are database-driven
You build a data lake or audit log is required including complete change history

Choose Outbox Pattern when:

You focus simpler operations
You manage and implement the application that is the source of data changes
You need explicit control over event schema and content
You implement event-driven architecture with self- or well-defined domain events

https://www.lotharschulz.info/2026/01/05/building-real-time-data-pipelines-with-cdc-outbox-postgresql-and-apache-nifi/

Jē, #RaxtIS ir fediversēts :)

vismaz proof-of-concept at #outbox

#Fediverse + https://raxtis.com

[Перевод] Паттерн Outbox для надежного обмена сообщениями в микросервисах

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

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

#net #net_core #csharp #csharpnet #c# #patterns #pattern #outbox #outboxпаттерн