Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech, а также преподаю на курсах по разработке и архитектуре в OTUS.

Сегодня предлагаю поговорить о фундаменте, на котором держатся современные распределенные системы, — о системах обмена сообщениями.

На собеседованиях я часто слышу аргумент: «Мы используем Kafka, потому что ее используют все» или «А что можно здесь использовать кроме REST?», то сразу понимаю: человек либо никогда не проектировал по‑настоящему высоконагруженный сервис с кучей интеграций, либо обжигался, но так и не понял почему.

Проблема передачи данных между сервисами только кажется простой. В реальности, стоит вам выйти за рамки «Hello World» в монолите, вы тут же упираетесь в стену: сетевые сбои, разные форматы данных, отказ одного из потребителей и каскадное падение всей системы. Мы в FinTech особенно остро это чувствуем. Платеж должен пройти или не пройти, но он не имеет права потеряться или задвоиться.

Давайте разберем не просто теорию про очереди, а ту самую архитектуру Каналов и Фильтров (Pipes and Filters), которая является краеугольным камнем любой надежной интеграции, будь то монолит с очередями или сотня микросервисов. И да, никакой магии, только инженерный подход.

Ложка дегтя в синхронную бочку меда

Разработчики любят синхронные вызовы. Дернул REST API, получил 200 OK или 500 Internal Server Error, пошел дальше. Код простой, логика линейная. Но давайте представим реальный кейс.

В одном из проектов мы строили систему обработки заказов. Клиент жмет «Оформить», а бэкенд в этот момент должен:

1. сохранить заказ в БД;

2. проверить стоп‑листы (мошенники);

3. дернуть складскую систему за остатками;

4. отправить письмо на email клиенту;

5. отправить событие в CRM для менеджеров.

Если делать это синхронно в одном потоке, пользователь будет смотреть на спиннер секунд 10–15. Если в этот момент отвалится «Склад» по таймауту, мы словили исключение. Что делать с заказом? Откатывать? А если письмо уже ушло? Начинается ад согласованности данных.

Именно здесь в игру вступает асинхронный обмен сообщениями (Messaging). Это не просто передача байтов из точки А в точку Б. Это философия построения слабосвязанных систем. Давайте разложим ее на базовые кирпичики, как это делали архитекторы задолго до появления модных фреймворков.

Кирпичики архитектуры: Каналы и Сообщения

Первое, с чем сталкиваешься, — это разделение понятий.

• Канал сообщений (Message Channel) — это не труба, по которой льется бесконечный поток битов. Это логический адрес. Полка, куда один кладет, а другой забирает. Важно понимать: изначально система пуста, каналов нет. Мы, как архитекторы, сами решаем, как назвать эти полки: order.created.queue, user.registered.topic, dlq.payment.failed.

• Сообщение (Message) — это атомарная единица данных. Заголовки и тело. Тело чаще всего сейчас — JSON, Avro или Protobuf, в нулевых был XML. Суть не в формате, а в том, что это законченный пакет информации, который должен быть доставлен и обработан целиком.

Я часто вижу, как команды пытаются гнать по очередям гигабайтные файлы. Это не лучшая практика. Best Practice: сообщение — это ссылка на файл в S3 или описание команды, а не само содержимое файла. Иначе вы получите не стройную интеграцию, а неповоротливый и неуправляемый функционал.

Сердце архитектуры: Pipes and Filters

Самое элегантное решение для обработки таких потоков — архитектура Каналов и Фильтров. Давайте визуализируем ее, чтобы было понятнее. Вот как выглядит базовая цепочка обработки входящего запроса:

В чем прелесть такого подхода? Каждый фильтр — это маленькая программа с одной ответственностью. Она берет сообщение из входного канала, что‑то с ним делает и кладет в выходной. Фильтры ничего не знают друг о друге.

На практике это дает сумасшедшую гибкость. Представьте, что завтра бизнес попросил добавить проверку по GeoIP. С синхронным REST‑кодом мы бы полезли в сервис заказов, добавили еще один if, провели регресс. С фильтрами мы просто:

1. Создаем новый фильтр GeoIPFilter.

2. Вставляем его в цепочку каналов.

3. Существующие фильтры даже не перезапускаются.

Более того, если один из фильтров (например, проверка на фрод) начинает тормозить, мы можем запустить не один, а пять его экземпляров. Это называется «Конкурирующие потребители» (Competing Consumers). Все они будут разбирать очередь параллельно, и пропускная способность вырастет кратно.

Маршрутизация: Как не заблудиться в лабиринте каналов

Простые линейные цепочки встречаются редко. Чаще всего сообщению нужно выбрать путь в зависимости от содержимого.

Здесь на сцену выходит Маршрутизатор сообщений (Message Router). И тут я хочу предостеречь от одной ошибки.

Одна команда реализовывала систему нотификаций. В ней был один канал notification.send. И один большой сервис, который парсил сообщение, смотрел на поле type и дергал внутри то SMS‑шлюз, то Email‑провайдера, то Push‑сервис. Выглядело логично. Но когда Email‑провайдер менял API, то приходилось пересобирать и перевыкатывать весь громозкий сервис нотификаций, рискуя при этом нарушить функционал SMS.

Правильное решение — вынести логику «куда отправить» наружу.

Best Practice: Маршрутизатор не меняет сообщение. Он только смотрит на заголовки или тело и перекладывает из одной корзины в другую. Изменением данных занимается отдельный фильтр — Транслятор сообщений (Message Translator).

Святая святых: Надежность и транзакционность

Сегодня в Enterprise‑разработке уделяется огромное внимание транзакциям. И это то, что в микросервисной разработке часто упускают.

В сети есть описание одного проекта где команда разработки использовала брокер сообщений, но без транзакционного чтения. Схема была: Получить сообщение -> Начать обработку -> Записать в БД -> БД упала -> Исключение. Что происходило с сообщением? Оно терялось. Брокер считал, что раз он отдал его клиенту, дело сделано.

Но это катастрофа для FinTech. Деньги не имеют права испаряться!

Чтобы этого избежать, нужно использовать паттерн Транзакционный клиент (Transactional Client). Суть проста:

1. Получаем сообщение из канала в рамках транзакции.

2. Обрабатываем и пишем в свою БД (также в транзакции).

3. Фиксируем (commit).

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

Но тут есть еще одна засада — дубли. Если падает не БД, а сеть в момент подтверждения коммита брокеру, брокер может решить, что мы не справились, и выдаст то же самое сообщение еще раз.

Здесь на помощь приходит Идемпотентный получатель (Idempotent Receiver). Механизм, при котором ключ сообщения (Message ID) сохраняется в БД вместе с данными. Если приходит дубль — мы просто игнорируем бизнес‑логику, но подтверждаем получение.

Давайте разберём этот процесс на схеме:

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

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

Идемпотентный получатель решает эту проблему элегантно: он хранит идентификаторы уже обработанных сообщений и при появлении дубликата просто подтверждает получение, не выполняя повторно никаких действий.

Это правило номер один при работе с любыми очередями: ваши обработчики должны быть идемпотентными. Даже если брокер гарантирует exactly‑once семантику (что на практике не всегда достижимо), защита на уровне приложения никогда не будет лишней!

Инновации и реальность: Как это связано с микросервисами?

Можно подумать: «Это же все базовые концепции MQ из нулевых, зачем мне это в 2026 году с моим кластером Kubernetes?»

Ответ прост: REST убивает микросервисы. Очереди их воскрешают.

Микросервисная архитектура по определению распределенная. Когда Сервис А вызывает Сервис Б по HTTP, они становятся связанными временем ожидания и доступностью. Если Б прилег отдохнуть (OOMKilled, переезд на другую ноду), А начинает сыпать ошибками.

Использование Шины сообщений (Message Bus) — будь то RabbitMQ, Apache Kafka или облачный Amazon SQS/SNS — разрывает эту связь. А отправляет событие ЗаказСоздан и забывает о нем. Жив Б в этот момент или мертв — А не волнует. Б проснется, прочитает накопленное и обработает.

Более того, современные брокеры вроде Apache Kafka реализуют модель Публикация‑Подписка (Pub/Sub) и Потоковую обработку, что позволяет строить аналитику и реактивные системы на порядок надежнее, чем REST‑костыли с retry‑логикой на стороне клиента.

Заключение: Система обмена сообщениями — это стратегия, а не просто утилита

Давайте зафиксируем Best Practices, к которым пришли за годы практики успешные команды:

1. Каналы по типам данных. Не мешайте регистрации пользователей и финансовые транзакции в одной очереди.

2. Идемпотентность превыше всего. Даже если вы используете Exactly‑Once семантику Kafka, ставьте защиту от дурака в коде.

3. Не бойтесь фильтров. Лучше 10 маленьких сервисов, которые легко тестировать, чем один большой комбайн.

4. DLQ (Dead Letter Queue). Сообщения с ошибками не должны забивать основную очередь. Они должны складироваться в отдельный канал для ручного разбора.

5. Мониторинг лага. Размер очереди — это первый индикатор того, что ваша система не справляется.

Разбор этой темы — это не попытка окунуть вас в мир легаси EAI‑систем. Это база для построения надежной микросервисной архитектуры. Если вы понимаете, как работают каналы, фильтры и маршрутизаторы, вы перестаете быть просто разработчиком, который клепает CRUD‑ы. Вы становитесь инженером, который видит картину целиком.

Если эта тема для вас актуальна и хочется разобраться в построении таких систем на практике (а не просто в теории), приглашаю вас на открытые уроки OTUS в рамках курса «Микросервисная архитектура». Там мы поговорим о том, как применять эти паттерны в коде, в Spring, в Kafka Streams и не только. Участие бесплатное, нужно только зарегистрироваться.

• 15 апреля в 20:00 «Основы проектирования бизнес‑логики в микросервисной архитектуре» ➭ Записаться на урок

• 23 апреля в 20:00 «Паттерны RESTful API. Как проектировать удобные, масштабируемые и гибкие API?» ➭ Записаться на урок

Всем стабильного прода!