Всем привет!
Этим постом запускаю серию про паттерн Saga - не в теории, а через реальный путь: от сломанной консистентности в распределенной системе до решения, поселившегося в продакшене. И к выводам, которые мы смогли вынести из этого опыта

В этой серии:

• как я вообще на него наткнулся
• почему «простые» решения перестают работать
• как сохранять консистентность в распределённых системах

ℹ️ Контекст:

В начале было слово, и словом этим было VCard.
Так мы называем наш сервис виртуальной карты, который позволяет гостям пользоваться преимуществами программы лояльности при заказах в ресторанах.

Работает это так:

• пользователь сканирует QR-код на столе
• видит заказ в мобильном приложении
• применяет карту - копит бонусы или списывает уже накопленные

Пользовательский флоу элементарный.
Системный - нет

➡️ Решение “в лоб”:

Когда мы реализовывали этот флоу, о паттерне Saga мы ещё не знали.

Решение выглядело логично:

• холдируем бонусы в CRM
• последовательно выполняем операции на кассе
• фиксируем результат
• при ошибке - откатываем все

Никакой магии,
никакой надёжности,
никакой согласованности 🙂

🧪 Тестирование:

На тестовом стенде всё работало как надо! Иногда всплывали редкие аномалии - примерно один случай из ста.

Мы списывали это на:

• ограниченные ресурсы стейджа
• нестабильность окружения
• тестовые данные

Обвиняли что угодно, даже ретроградный Меркурий,
лишь бы не откладывать релиз нового пользовательского сервиса

🛑 Продакшен:

Продакшен очень быстро показал,
насколько сильно мы ошибались.
И за эту ошибку пришлось заплатить кратно

С ростом нагрузки редкие сбои
превратились в поток инцидентов

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

Стало совершенно ясно:
• это не единичные баги
• и не «особенности окружения»

❗️Это - системная проблема в реализации сервиса

⏯️ В следующий раз я расскажу:
• как мы начали разбирать эти инциденты
• какие закономерности нашли
• и почему в итоге упёрлись в вопрос консистентности
в распределенной системе

Blue Green №3

Продолжение серии статей про паттерн Saga. В прошлый раз мы остановились на том, что после релиза стало понятно - что проблема системная. И что проблема сама по себе никуда не денетеся. Но еще непонятно, в чем собственно проблема

❗️Инциденты повторялись.
❗️Поддержка тонула в обращениях.
❗️Поведение системы выглядело нестабильным и непредсказуемым.

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

🔍 Что мы сделали:

• усилили логирование
• добавили трейсы
• начали группировать инциденты

И довольно быстро стало ясно - это не хаос. Все инциденты укладывались в несколько повторяющихся сценариев:

• Нарушение идемпотентности при слабой сети
• блокировка заказа операцией на кассе или официантом
• таймауты операций, когда касса нагружена

Сценарии разные, последствия разные - но эффект всегда один

❗️Нарушена консинстентность данных в системе

Система регулярно оказывалась в состоянии, когда часть шагов выполнена, а часть - нет

Мы не могли точно ответить:

• что сейчас происходит с заказом
• какие действия уже применены
• и что именно нужно откатить

❓ Ключевой вопрос:

В какой-то момент вопрос стал предельно конкретным:

Как сохранять консистентность в распределённой системе
без общей транзакции?

С этим вопросом я пошёл искать ответы, тогда еще с поисковиком. Были же времена...

▶️ И тут появляется Saga

Через несколько статей я наткнулся на упоминание паттерна Saga, а затем — на его классическое описание на microservices.io

Saga предлагает смотреть на бизнес-операцию не как на одну транзакцию, а как на последовательность локальных шагов с описанием явных компенсирующими действий на каждом этапе

▶️ В следующих постах я расскажу:
• Как мы реализовывали Saga технически
• Почему выбрали режим оркестрации
• С какими граблями столкнулись в продакшене

Заканчиваю серию постов про паттерн Saga. В прошлый раз я остановился на моменте, когда стало понятно, что без управления распределенной транзакцией проблему консистентности не решить.

В этом посте - подробнее о реализации Saga в системе

➡️ Выбор подхода:

Saga можно реализовать через:
• хореографию
• оркестрацию

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

Причины:

• сложная работа с кассовым оборудованием
• необходимость строгого контроля последовательности шагов
• таймауты, ретраи и явные переходы состояний

При этом сервис масштабируется горизонтально,
и управление шагами передаётся между инстансами через Kafka.

⚜️ Базовая идея реализации:

Главное ограничение - пользовательский флоу нельзя менять.
То есть имплементация Saga в проект должна быть бесшовной

Поэтому архитектура построена так:

• перед стартом Saga сохраняется копия заказа
• каждый шаг изменяет только копию
• основной заказ обновляется только после успешного завершения всех шагов

Это позволило:

• безопасно выполнять откаты
• избежать полусломанных состояний
• понимать текущее состояние транзакции

🧩 Типы Saga в системе:

В системе выделены три основных сценария:
• COMMIT - применение карты в заказ или досписание бонусов
• CANCEL - отмена применённой карты
• SUBSCRIBE - изменения заказа, инициированные кассой

Каждый сценарий разбит на атомарные шаги
с компенсирующими действиями: блокировка заказа, выполнение бизнес-условий в CRM и на кассе, разблокировка заказа

🛑 Broken Saga:

Если во время отката что-то пошло не так - Saga помечается как Broken

Дальше:

• сага уходит в фоновую обработку
• выполняются повторные попытки отката
• при неудаче требуется ручное вмешательство

Это не идеальное решение, но понятное и лёгкое в поддержке.

🚨 Продакшен-грабли:

После релиза система работала стабильно.
Ровно до первого серьёзного пика нагрузки.

Из-за задержек на стороне кассовых демонов:

• шаги перестали укладываться в TTL
• Saga начали падать на этапе блокировки заказа
• для обработки Broken Saga первый шаг всё ещё пытался заблокировать заказ
• задержка на кассе спровоцировала лавинообразное создание саг, приведя систему к отказу
• в отдельных случаях на один заказ создавались сотни Saga

Проблему пришлось решать экстренно:
🔸 Усиливали демонов
🔸 Переезжали на новые топики
🔸 Принудительно откатывали активные Saga

После переработки флоу обработки Broken Saga эти проблемы нас больше не беспокоили.

✅ Итоги:

Saga не упростила систему. Она сделала её управляемой, но при этом значительно сложнее

Что изменилось:
🔹 Восстановилась консистентность
🔹 Пользовательский флоу стал стабильным
🔹 Поддержка перестала вручную разруливать зависшие списания

Новые баги появились, но теперь они локализованы внутри Saga, а не размазаны по всей системе.

🔄 Промежуточный вывод:

Я однозначно напишу отдельный пост-рефлексию об этом опыте, но, завершая серию, хочу зафиксировать:

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

❗️ Конец Blue-Green: мы выбрали процесс вместо костыля

В прошлой части остановился на вопросе: «строим систему надёжнее или умный костыль, который однажды станет нашей главной точкой отказа?»
Сегодня - ответ. И он не тот, который я планировал

➡️ Куда мы пришли технически
К моменту ревью всё почти работало:
DevOps выкатили Blue-Green в продакшен: два окружения, единый ingress, переключение трафика по кнопке activate {color}
Со стороны Django: пропатченная команда makemigrations, разделение операций на конструктивные и деструктивные, тулинг для двухфазных миграций
На горизонте - переход на дневные релизы. Цель, ради которой всё затевалось

Оставалось пройти код-ревью и описать процесс работы с новой схемой
🛑 Тех.лид пришёл с альтернативой
На ревью пришёл наш тех.лид - назовём его Серёга. И принёс ссылку на статью про паттерн Expand & Contract. По его мнению - вот правильный способ решать совместимость схемы БД. А моя реализация ему «не нравится»
Я уперся рогами. Двухфазные миграции работали, корнер-кейсы отрабатывали - я готов был защищать решение до последнего

🔍 Архитектурный комитет как место для дебатов
На архком мы приходили не раз и не два
Серёга стоял на том, что задача решается процессом. Я - на том, что процесс нужно подкрепить технологией, чтобы переход был безболезненным
Каждый раунд уходили в детали, прорабатывали корнер-кейсы, возвращались с новыми аргументами. Серёга не мог доказать, что моё решение не работает. Я не мог честно объяснить, зачем оно нужно поверх процесса
В фоне всё это время висел один вопрос: «зачем»

💡 Кто потребитель схемы БД
Озарение пришло на одном из таких ADR. Простой вопрос: на кого вообще рассчитан этот механизм совместимости?
Я строил систему, которая поддерживает консистентность для двух потребителей - Blue и Green. То есть для двух версий бэкенда
Но у схемы БД потребителей сильно больше: смежные сервисы, отчёты, аналитика, фоновые задачи, внешние интеграции. Технология даёт контракт ровно для двух клиентов. Для всех - нужны бесконечные деньги и ресурсы, которыми мы, к сожалению, не обладаем
А корректно работающий процесс - покрывает 100% случаев. Не в вакууме, а в реальной жизни. Это не так элегантно, как техническое решение в идеальных условиях. Но несоизмеримо эффективнее

✅ Финал
Я сдался. Признал капитуляцию, отпустил рога и пошёл внедрять процесс
Цель осталась той же - Zero Downtime и дневные релизы. Изменились только средства. Через неделю после последнего архкома мы выкатили первый релиз в дневное время. Без костыля, только на процессе
Эта история длиной в 3.5 года потом легла в основу моего доклада на Moscow Python №107. Финальный тезис серии и доклада совпадает:

Не пишите костыли, процессы рулят

А Серёга оказался единственным голосом разума на всю компанию. Я слишком долго не верил, что проблему нельзя решить технически. В итоге пришёл к тому, что можно - но не полностью

👋 Вчера был на встрече с программным комитетом Saint HighLoad!

Записался туда, по большей части, из любопытства
Пока что выступления на конференциях такого уровня кажутся мне чем-то сверх
Хотелось взглянуть на их кухню, пообщаться с людьми и в целом полезно провести вечер
Возможно, унести с собой какие-то инсайты

🔍 Ничего неожиданного не произошло - и это, пожалуй, главное наблюдение

Я увидел людей, которые уже выступали раньше, выступают сейчас и будут выступать дальше
Пообщался с организаторами, с опытными и начинающими спикерами, СТО и СЕО местных компаний, юристами из бигтехов
И все-таки кое-что я понял:

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

🍺 Про формат встречи

Мероприятие проходило в полуподвальном барном помещении
Видимо, чтобы забустить нетворкинг легким градусом пенного. И у них получилось!

В начале организаторы рассказывали об основной цели встречи - донести обновленный формат и манифест конференции 2026 года
Основная идея простая:
- учить значит вовлекать!

🧠 Про формат обучения

Дальше много раз подчеркивалось, что приоритет будут отдавать интерактивным форматам
Воркшопам, обсуждениям, экспериментам с залом

Последний спикер показал это на практике
Один приветственный слайд и вопрос в зал:

Что должно быть на конференции, чтобы на нее прийти?
И что - чтобы прийти, заплатив из своего кармана?

Дальше были споры, примеры и живые реакции
Ровно тот формат обучения, о котором все и говорили

⚖️ Про напряжения и ограничения

Название HighLoad по-прежнему многими считывается как история только для бигтеха
Хотя в зале было много людей из маленьких команд с сильным и интересным опытом

Отдельный холивар вызвала тема HR бренда
Всем интересно слушать не только про успехи
А про внутреннюю кухню, ошибки и рост
Но именно эти темы чаще всего не проходят корпоративные фильтры BigTech

🔁 Про более широкий сдвиг

Если вынести это за рамки одной конференции, становится заметен более общий сдвиг
Информация сегодня перестала быть ценностью сама по себе
Базовые знания можно получить за вечер
Но понимание без опыта не держится

Чтобы действительно чему-то научить, нужно вовлекать
Давать возможность думать, спорить и ошибаться
Создавать опыт, а не просто передавать информацию
И именно это я увидел на встрече
В формате и поведении людей

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

✔️ В конце у меня удалось пропитчить несколько своих идей и получить ценную обратную связь от зала и от организаторов. Буду пробовать подавать! Кто знает, что из этого выйдет?

#MINDSET #NOTES

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

Обсудил проблему с коллегами, и мой друг протянул мне умную салфетку - NapkinAI. Napkin с английского, как раз, салфетка

Первый опыт - действительно впечатляющий 🔥
Вставляешь текст - получаешь вменяемую схему. Быстро, аккуратно, клёво. Ровно то, что нужно для презентации. Но бесплатные токены заканчиваются почти сразу же. Их не хватило даже чтобы собрать финальную визуализацию к одному слайду. Большая часть ушла просто на изучение возможностей

👀 Смотрю на подписки. Уже в минимальной обещают брендинги, кастомные стили, шрифты, шаблоны. Думаю:"То, что нужно!". Закидываю 12$ и оплачиваю подписку, ожидая, что работа больше не будет ограничена, и, заодно, почти полностью автоматизирована

❌Начав использование разочарование не заставило себя ждать. По факту платная подписка дала мне только дополнительные токены и отсутствие ватермарки NapkinAI. Брендинг не работает, стили не сохраняются, шрифты не добавляются. Весь "платный" функционал либо сломан, либо работает нестабильно. Особенно огорчило то, что цвета не просто не "брендируются", а любое обновление требуется прожать несколько раз, чтобы применить

💊 В итоге каждую визуализацию пришлось вручную доводить до брендинга презентации - править цвета, шрифты, стили. Делать ровно то, что инструмент, по идее, должен был взять на себя за оплаченную подписку

Да, задачу "быстро получить заготовку" NapkinAI решает, в целом инструмент оказался не более, чем "умным шаблонизатором визуализаций", и, в целом, проблему он решает. Но не ту, за которую меня вынудили заплатить

✍️ В сумме опыт получился максимально противоречивым. Продавай они отдельно токены, без платных фич - вопросов бы у меня не было. Но было так, как было...

✍️ Ранее писал, как мы уперлись в проблему воронки:
пользователь открывает меню - и не добавляет в корзину. Одна из гипотез - пользователь не справляется с тягостью выбора из сотен позиций. Мы решили проверить, как AI-ассистент, сократив выбор, поможет пользователю дойти до целевого действия - покупки.

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

Мы смотрели на:

• Поведенческие паттерны клиентов
• На каком запросе чаще всего происходит добавление в корзину
• Следили за метриками здоровья продукта
• Считали, сколько будет стоить продукту содержание ассистента

По сути, мы тестировали не фичу — мы тестировали ее экономику. Важно было заранее понять, влезаем ли мы в юнит-экономику до запуска полномасштабного эксперимента.

📊 После этого запустили основной A/B-тест, он идет 3 недели и раскатан на 100% пользователей — соответственно, доступен половине (50%). Основная цель эксперимента - проверить влияние на конверсию.

И вот здесь становится интереснее: почти сразу зафиксировали полезный инсайт.
У пользователей есть повторяющийся запрос, который логично упаковать в отдельную категорию. Так и сделали. Готовим запуск новой категории на основе реального поведения, а не ощущений.

❔ Почему 3 недели?
• Потому что нам нужна статистическая устойчивость
• Нужно собрать достаточный объем данных
• И отделить реальный эффект от шума короткого периода

⏳ После завершения теста мы не будем сразу масштабировать. Закладываем ~пару недель на анализ результатов

Будем считать:

• Сколько фича фактически заработала
• И во сколько она фактически нам обошлась
• Как повлияла на юнит-экономику
• Какие сценарии развития окажутся наиболее перспективными

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

AI здесь не эксперимент ради эксперимента. Это новый рабочий слой продукта.
И мы пока только формируем внутрикомандное представление о том, что именно будет находиться в этом слое

💡Последние полгода на Инициативных Комитетах обсуждаем инициативу командной подписки на AI-инструменты. Бюджет небольшой - примерно стоимость одного middle-разработчика в год

Изначально инициатива называлась «Подписка на Cursor». Мы рассматривали Cursor как основной инструмент и думали, скорее, о компенсации расходов разработчиков на agentic-tools, а не о развитие инженерной культуры. Но по мере обсуждения отказались от привязки к конкретному решению

Сейчас ориентируемся на бюджет около $50 в месяц/рабочее место. Идея в том, чтобы дать команде возможность экспериментировать и сравнивать подходы: IDE-ассистенты, CLI, агентские режимы, API для внутренних ботов и прочее

📈 Сначала обоснование строили через рост эффективности
Строили финансовую модель. Пытались говорить про ускорение отдельных этапов разработки. Приводили реальные примеры вайбкодина в нашем продакшене

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

И главное - такая аргументация формирует опасные ожидания у управляющей компании

🔀 Поэтому мы поменяли подход. Теперь мы не обосновываем ИИ как инструмент ускорения разработки. Мы рассматриваем его как инвестицию в инженерную зрелость команды

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

🛠 Три недели на Claude Max — и Cursor мне больше не нужен

Шла третья неделя использования Claude Max(20x) по подписке, и, впервые за полгода, я не проплатил подписку на Cursor. Пока мы прорабатывали инициативу ИИ Просвещения в компании, я перепробовал кучу подходов и инструментов. Как и писал выше — от идеи тащить корпоративный Cursor мы отказались почти сразу

🔍 Cursor — хороший инструмент. Мультимодели из коробки, широкие возможности. Но всё, что он делает — он делает вокруг оболочки VS Code, которая мне просто не нравилась. В итоге висела проплаченная подписка, идеи я прорабатывал в ChatGPT, а когда нужно было жёстко по-вайбкодить — открывал Cursor, но редко упирался даже в их приземлённые лимиты

🛑 Главная проблема Cursor — и для меня, и для программы Просвещения — в том, что он слишком легко даёт результат. Как Windows Forms в Visual Studio: создаёшь Button, переходишь в OnClick, описываешь всё поведение прямо там. Код работает — но ты не думаешь ни о парадигмах, ни об абстракциях. Cursor устроен так же — он прячет сложность за красивой оболочкой, и человек получает результат, не понимая, что именно произошло. Для обучения это антипаттерн

💡 Я не планировал переезд, просто хотел потестировать Claude. Но уже за первую неделю он стал моим персональным помощником №1. Сам помог настроить окружение, рассказал, как правильно управлять контекстом, автоматизировал несколько рабочих процессов за короткие вечерние сессии. Постепенно даже планирование переехало из ChatGPT — управление проектами и интерактивные дорожные карты в Claude Chat с лихвой перекрыли аналогичные фичи ChatGPT

⚠️ Жаль, что Anthropic вынуждены вести агрессивную финансовую политику. Использовать Claude через сторонние инструменты вроде OpenCode можно, но только через API-токен, где обычный проход по контексту проекта легко переваливает за $100

Три недели мне хватило, чтобы определиться. Одна подписка заменяет всё: ChatGPT, Cursor, китайские GLM'ки. Больше никакого зоопарка инструментов. Один ассистент - один рабочий процесс ☝️