Flow

Это была отраслевая конференция, менее масштабная, но покорившая меня своей особой атмосферой. Если у вас накопились вопросы по специальности, то здесь легко удается оперативно познакомиться с людьми, которым можно задать интересующие вас вопросы. Мне особенно запомнился скрупулёзный подход организаторов ко всем деталям мероприятия: начиная от зон для обсуждений возле залов и заканчивая наличием гримёра прямо на площадке. Важнейший критерий оценки любой конференции — уровень выступлений, и тут он оказался безупречным. Общаясь с организатором, человеком глубоко погружённым в сферу ИТ, поняла, почему мероприятие получилось таким уютным и комфортным для участников: оно создано именно айтишниками для айтишников, где не соскучишься ни на официальных секциях, ни на развлекательной программе.
Главное слово, характеризующее для меня эту конференцию, — «уют».

Не могла не прислать. Что думаете: "совсем поехавшие" или "жиза"?

Хочу поговорить с вами об асинхронности. Разговор предстоит длинный, и прежде чем мы начнем, предлагаю четко разграничить 2 понятия: очередь и брокер.
Возможно, для большинства присутствующих мое предложение покажется странным, потому что всё и так понятно, зачем говорить очевидное...
Но многократно на собеседованиях кандидаты встают в тупик, когда я спрашиваю: очередь и брокер - это одно и то же? Цель такого вопроса не завалить человека, а понять, любит ли он свою профессию, чтобы вникать в вопросы чуть глубже, чем иногда требуется. Как относитесь к такой позиции? Расскажите в комментариях, по какому нестандартному принципу вы отличаете подходящего кандидата?

⛓️‍💥 Очередь

Очереди используются для хранения сообщений в порядке поступления и обработки их последовательно: первый пришел - первый вышел.

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

⛓️ Брокер сообщений

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

Особенности
- Поддерживает модели "publish-subscribe" (pub/sub), позволяя множеству потребителей получать одно сообщение одновременно.
- Является частью асинхронного мира
- Работает на протоколах передачи сообщений (AMQP, MQTT и тд)

Недавно нашла вот такой полезный доклад о стоп-словах аналитика. Показался очень полезным, поэтому показываю вам

кто интересуется архитектурой ИИ, тому полезно будет узнать о митапе Сбера
16 декабря с 11.00

Приступим к асинхронности. Она, конечно же, скрывает много подводных камней, которые мы и начнем поднимать со дна :)
Асинхронные системы давно стали модным архитектурным выбором. «Поставим Rabbit/Kafka — и всё взлетит» звучит примерно как «перепишем на микросервисы — и станет быстрее» 😆😆😆.
На практике же асинхронность — это не инструмент, а архитектурное мировоззрение, которое меняет буквально всё: от того, как устроена модель данных, до того, как работает команда разработки и как взаимодействуют с системой пользователи.

Недавно поймала себя на мысли, что мне очень нравится делать разборы в формате развенчивания мифов (часть из которых и были моим мнением, пока я не стала копать). Ниже — разбор основных иллюзий, с которыми сталкиваются команды, делая первые шаги в сторону асинхронности.

🪝 Скрытая синхронность: RPC поверх брокера и его ловушки

Первая ошибка, в которую попадают команды: пытаясь уйти от синхронного REST, они переносят те же паттерны поверх брокера сообщений. Возникают решения вида RPC over MQ, где:
— сервис A кладёт сообщение в очередь
— сервис B обрабатывает его и отправляет ответ в «reply queue»
— сервис A продолжает выполнение после получения ответа
На бумаге — асинхронность. На практике — тот же синхронный вызов, только скрытый в очередях и callback’ах.
Чем это опасно?

1. А смысл?
Команда думает: «Мы же используем брокер, всё асинхронно». На деле — они не избавились от синхронности, а просто спрятали её глубже, добавив ещё больше точек отказа.

2. Хрупкость цепочки
Теперь между клиентом и исполнителем не один сетевой хоп, а два, три или четыре: публикация, маршрутизация, обработка, обратная публикация. Любой сбой превращает ответ в «висит, но непонятно где».

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

🗼Итог: RPC поверх брокера ломает саму идею асинхронной архитектуры, превращая её в более сложный вариант привычного синхронного вызова.

Merge Baltic

Продолжу тему впечатлений о конференциях.
Конференция бренда Merge "сложилась" для меня лишь со второй попытки. Первый мой доклад отклонили, после чего стало ясно: углубленное изучение технических деталей здесь не всегда интересно. Поэтому я решила сменить тактику и предложила более философски ориентированную тему — и вот тогда мое выступление вошло в официальную программу мероприятия.

Самое яркое впечатление произвело место проведения: Светлогорск, уютный город в живописнейшей Калининградской области. Эта территория сама по себе похожа на природный музей-заповедник, наполненный чудесами природы. К тому же мне повезло попасть сюда именно осенью, когда золотые краски листвы сделали атмосферу особенно чарующей.

Теперь поговорим непосредственно о самом событии.

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

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

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

Если охарактеризовать конфу одним словом — это дух «small talk»: непринужденные беседы и диалоги, формирующие живую интеллектуальную среду для всех участников.

Переходим к следующему мифу.

⚓️ Когда eventual consistency — это не про данные, а про бизнес-процессы

Моя "любимая" согласованность... в кавычках, потому что, мне кажется, я на своих докладах всем вынесла мозг с ней. Рассмотрим очередную ее грань...

Асинхронность часто связана с eventual consistency: данные рано или поздно синхронизируются. Это звучит безобидно — пока не проявляется в пользовательских сценариях...

Пример: заказ создан, но платёж «где-то едет»

Пусть пользователь оформляет заказ. Фронтенд получает успешный ответ: «Заказ создан». Через секунду он открывает историю заказов — а там заказа нет, потому что поток обработки платежей задержался, и сервис заказа пока не обновил статус.
Что думает пользователь?
«Сайт сломался, надо оформлять заново». Даже если бизнес-процесс формально корректен, пользователь все равно идет оформлять повторно.

Вот что стоит помнить:
🎲 Eventual consistency — это не только про репликацию данных.
Это про рассинхронизацию реальности и того, что видит пользователь!! Поэтому асинхронность вынуждает продумывать UX иначе.

🎲 Нужно объяснять пользователю, что происходит: «Платеж обрабатывается…». А это означает изменения интерфейса, API, состояния в БД, SLA на задержки.

🎲 Асинхронная архитектура = асинхронный бизнес.

🎲 Процессы меняются: появляется потребность в сагах, компенсационных транзакциях, промежуточных состояниях.


Иными словами, внедряя асинхронность, вы меняете не только технологию, но и то, как бизнес работает с реальностью.
Казалось бы, очевидное утверждение. Но оно не всегда вспоминается при проектировании. Поэтому призываю вас ❗️ сделать это утверждение своей парадигмой, когда вы проектируете асинхронные процессы.

Analyst Days
Финальная конференция сезона и знаковое событие в мире аналитики — AnalystDays. Давно мечтала посетить её лично, и вот, наконец, моя мечта сбылась именно в этот год!

Особенно приятно осознавать, что хотя конференция ориентирована исключительно на системный и бизнес-анализ, ей удаётся сохранить впечатляющий размах и привлечь огромное количество профи. Только спикеров в этом году больше сотни!
Для меня важным показателем уровня мероприятия является тяжелый выбор, на какой доклад пойти, тк сразу несколько интересных тем рассматривается одновременно. Такое со мной случается не на каждой конфе.

Несмотря на масштаб, атмосфера остаётся дружелюбной и располагающей к нетворкингу. Можно легко найти собеседника по любой интересующей теме, включая идеи будущих докладов с программным комитетом.

Отдельного восхищения заслужило афтепати. Танцы помогают разрядить обстановку и снизить серьёзность, что способствует более неформальному общению среди участников. Я думаю, дискотека должна стать обязательным элементом афтепати каждой крупной конференции. Согласны?

Уже сейчас начинаю подготовку к новому сезону и активно собираю свежие мысли и идеи. Очень надеюсь на вашу помощь и поддержку: расскажите о направлениях, которые вам интересны.
Как вызнаете, я люблю практические кейсы и конкретные решения конкретных проблем, поэтому сухие мотивационные лекции вроде "как оставаться в ресурсе" меня ещё не зацепили. Если у вас есть интересные задачки, буду рада ознакомиться с вашими мыслями.

А у меня вышла статья про мифы REST. го читать!

Привет всем! 👋

Пока все втягиваются в рабочий ритм, хочу поделиться одним маленьким, но (как теперь выяснилось) волшебным лайфхаком. Кажется, он спасает от всего.

Встречайте — Его Величество Цифровой Детокс. Что-то новое? Нет, конечно. Но мы, вечно спешащие и уставшие жители мегаполисов, его силу явно недооцениваем. Давайте я вас немного подтолкну в эту сторону. 😉

А для понимания масштаба катастрофы, расскажу, с чем я подошла к старту (работу в список не включаю — это и так понятно):

1. Шёл третий год материнства. На этом список можно было бы и закончить, но я продолжу.
2. Материнство — это четверть «беды». Активная мама — ещё четверть. Я таскала ребёнка везде с собой, а когда она подросла и заинтересовалась — мы ходим на все детские мероприятия города. Контроль над их количеством был безвозвратно утерян.
3. Летом ребёнок научился оставаться без меня больше суток, и тут Остапа понесло... Я так рьяно бросилась навёрстывать три года «упущенной свободы», что окружающих мой график начал пугать сразу, а меня — только к концу года. Сначала было 10 событий в квартал, потом — за два месяца, а в декабре я насчитала 17 мероприятий (из них 9 детских!),где требовалось моё участие и подготовка!. Семья шептала: «Остановись!», а съезжающая кукуха сыпала предложениями: «А давай ещё вот это придумаем!».
4. Еще четверть "беды" - это проекты, в которые я иногда вписываюсь просто потому что мне интересно. Это тоже время и затрачиваемая энергия, хоть и "по любви"
5. Кажется, четыре четверти — это уже целое, а значит пятого пункта уже быть не должно. Но я перевалила даже за него и добавила профессиональное развитие, в которое погрузилась с головой. Тянет на добрую треть, не меньше.

Итог: 1 целая и 1/3 «беды». Голова дымится, усталость накапливается, а концентрация — где-то потерялась и не хочет возвращаться.

Планируемое лечение

30 декабря, когда я закрыла рабочий ноутбук, в голове щёлкнуло: впереди не просто праздники. Впереди 12 дней, когда гарантированно отдыхают абсолютно все. А это волшебное окно, когда ни одна из моих «четвертей беды» не станет меня искать. Это ключевое отличие от обычного отпуска, когда что-то где-то случается и нужно «просто на минутку» подключиться, убивая весь эффект отдыха.

Решение созрело: полный цифровой детокс. Отрекаюсь от соцсетей, маркетплейсов и любых напрягающих контактов. Общение — только с самыми близкими. Телефон — только по делу.

Честно, такой эксперимент я проводила лишь раз в жизни, ещё студенткой. Тогда это казалось роскошью. Сейчас — необходимостью.

Реализация замысла

Дни 1-3: Палец на автопилоте трижды тянулся к иконке соцсети и успевал тапнуть, прежде чем мозг протестовал. Я сразу выходила, так что не считается! 😅
Книги! Я и так читаю перед сном, но тут... 2 большие книги за 12 дней! (Разумеется, ребёнок был у бабушки — без этого чуда бы не случилось). Это было восхитительное погружение, как в доматеринские времена.
«Потом почитать»: В браузерах накопилась гигантская (штук 20, для меня это много!) коллекция вкладок, покрытых цифровой пылью. И знаете что? Я до них добралась. Просто потому, что больше не было, куда спешить.

Итог

1. Я счастлива. Без лишних слов.
2. Голова не просто очистилась — она замедлилась. С моим темпом жизни это ощущается как ледяной душ посреди жаркого дня. Невероятная ясность.
3. Исчезло «рваное внимание». Помню из курса по ОС, что переключение контекста для процессора часто дороже самой операции. Наш мозг — та же система. Когда его не дёргают каждые пять минут, он начинает работать качественнее.

Что теперь (или главный инсайт)

Вернувшись в рабочие будни, я не почувствовала того привычного ужаса перед шквалом задач. Дело в другом: я теперь внимательнее отношусь к тому, что именно беру в голову. Прежде чем вписать новую активность в график, я на секунду задумываюсь: «А какой урон это нанесёт тому хрупкому спокойствию, которое сейчас царит у меня внутри?». И это, пожалуй, самый ценный вывод из всего эксперимента.

Что хочу порекомендовать

1. Если в отпуске есть возможность отключить телефон или соцсети — сделайте это! Рука тянется только первые три дня. Перетерпите, и уже через неделю вы себе скажете спасибо.
2. Даже если возможности нет — зафиксируйте в памяти это состояние «обнуления» после отдыха. Когда на вас обрушится шквал задач по возвращении, это чувство поможет продлить эффект отдохнувшей головы.
3. Замедляйтесь. Искусственно, нарочно, по принуждению. Просто попробуйте. У меня на этот счёт ещё много мыслей, но об этом — в следующих сериях. Не переключайтесь! 😉

А вы практикуете цифровой детокс? Или, может, боитесь даже попробовать?

Продолжаем тему асинхронности. Предыдущие статьи:
eventual consistency про бизнес-процессы
RPC поверх брокера и его ловушки

Брокер как единая точка отказа: миф о магической отказоустойчивости
Широко распространён миф: «Сделаем через очереди - и система станет устойчивее». Но брокер - это такой же критический компонент, как база данных. Иногда даже более критический: возможность передать событие - это кровеносная система архитектуры.

❓Что происходит при падении брокера?

🔸Продюсеры не могут отправлять сообщения. Бизнес замирает
Если продюсер не может опубликовать событие о завершении заказа, оплате или изменении данных, бизнес-процесс останавливается на самом старте.

Решение: outbox паттерн
Когда Продюсер публикует сообщение напрямую в брокер в рамках бизнес-транзакции - это считается плохим тоном. Вместо этого в рамках той же транзакции с БД, запись о событии сохраняется в специальную таблицу outbox в локальной базе данных сервиса. Это гарантирует атомарность: либо бизнес-данные и событие сохранены, либо нет. Отдельный, легковесный процесс забирает записи из outbox и отправляет их в брокер. Если брокер недоступен, процесс ждет и повторяет попытки с настроенной задержкой. Событие будет доставлено, когда это станет возможным.
В моей практике бывали случаи, когда эту outbox-таблицу приходилось разбирать руками, когда брокер больше 6 часов не мог забрать данные. Но это скорее исключение.

🔸 Консьюмеры перестают получать сообщения. Фоновые задачи умирают
Сервис-консьюмер, обрабатывающий уведомления или обновляющий кэши, становится бесполезным. Накопление очереди — это меньшее зло, чем полная остановка обработки.

Решение: Стратегия «Живучего консьюмера»

▪️Health Checks и Circuit Breaker: Консьюмер должен предоставлять строгий эндпоинт здоровья (/health), который проверяет не только его процесс, но и соединение с брокером и состояние потребления. Оркестратор (как правило, Кубер) должен рестартовать узел при проблемах.

▪️ Контрольные точки во внешнем хранилище: Не полагайтесь только на встроенный механизм коммитов брокера. Для критических задач периодически сохраняйте позицию обработки (ее еще называют смещением) в надежное, возможно, даже локальное дисковое хранилище. Это позволяет после сбоя начать не с последнего коммита в брокере (который мог быть потерян), а с известной безопасной точки.

▪️Изоляция обработки от потребления: Используйте паттерн «Конкурентный консьюмер» с внутренней очередью. Один поток читает из брокера и складывает сообщения во внутреннюю in-memory очередь (с лимитом), а пул рабочих потоков их обрабатывает. Падение брокера остановит только поток-читатель, а обработка текущих задач завершится.

...Асинхронность даёт новые формы отказов, а не избавляет от них.

Продолжаем тему проблем Брокера. Предыдущие части
eventual consistency про бизнес-процессы
RPC поверх брокера и его ловушки
Брокер как единая точка отказа - часть 1


Лавина повторных попыток после восстановления
Миллионы отложенных сообщений хлынут на только что очнувшиеся сервисы и добьют их.

Решение: Делаем лавину управляемой и превращаем ее в поток
♦️Rate limit на уровне продюсера: Процесс, считывающий таблицу Outbox не должен бездумно выгребать все накопившиеся сообщения. Используйте семантику LIMIT в запросе к outbox и паузу (возможно даже, экспоненциальную) между итерациями. Таким образом восстановление получится плавным.

♦️Rate limit на уровне потребителя: Консьюмер должен уметь замедляться сам. Используйте механизмы брокера (например, fetch.max.bytes и max.poll.records в Kafka) для уменьшения объема данных за одну итерацию при обнаружении высокой нагрузки или ошибок обработки.

♦️Приоритизация: Если это возможно, делайте приоритеты у очередей и топиков. При восстановлении в первую очередь обрабатываются критические события.


Каскадные сбои и бизнес-дедлоки
Сервис А ждет события от сервиса Б, который не может его отправить. Система впадает в состояние распределенного дедлока, но на уровне бизнес-логики.


Решение: Проектирование для частичной деградации и таймаутов
♦️Сага (моя любимая): Еслив вашем случае это возможно, то разбейте бизнес-операцию на этапы. А Сага позволит сделать эти этапы независимыми друг от друга, но при этом связанными событиями.

♦️Таймауты и статусы «Ожидание»: Любое ожидание события в бизнес-процессе должно иметь четкий таймаут. По его истечении процесс переходит в статус "требуется ручной разбор" или запускает компенсацию. Мониторинг таких «зависших» процессов — ключевая метрика.

♦️Асинхронные HTTP-вызовы с колбэками: Иногда лучше не ждать событие через брокер, а отправить команду по HTTP, немедленно получив 202 Accepted и id операции. Сервис-получатель позже отправит результат на заранее оговоренный callback-url. Это делает ожидание явным и управляемым. Это самый распространенный паттерн при генерации отчетов


Брокер, не болей! :)

Привет, друзья!

Хочу рассказать о классной онлайн-конференции для Системных аналитиков
🖤 Analyst Marathon 16 🖤

📅 7 февраля 2026 📅
будем усиленно обсуждать вопросы архитектуры, интеграции, безопасности и инструментов разработки. 80% спикеров знаю лично и совершенно точно могу рекомендовать доклад каждого из них.

Вы узнаете:

💟 Как грамотно выбирать гибридные архитектуры и эффективно интегрироваться с асинхронными системами.
💟 Какие методы и практики необходимы для безопасной работы с API и обработки данных.
💟 Современные подходы к созданию сервисов и платформ, включая работу с искусственным интеллектом и low-code инструментами.


Купить билет можно здесь
🎉 А я разыгрываю 1 бесплатный билет. Первый, кто в комментариях к этому посту ответит правильно на оба вопроса, получит промокод на билет. Вопросы, конечно, связаны с темой, которую разбирали последней

Вопросы:
1. Что может произойти с брокером, если потребитель будет обрабатывать сообщения медленнее, чем продюсер их отправляет?

2. Как называется основная единица хранения данных в Apache Kafka, внутри которой сообщения упорядочены и неизменяемы?