А вот теперь о вкусном....
🔆 Ненадёжность «надёжных» доставок: идемпотентность как единственный реальный гарант
привет и спасибо, Андрей Бураков! :)

На своих воркшопах Андрей всегда погружает участников на те низкоуровневые операции над которыми ты сам обычно не задумываешься. На одном из таких воркшопов подробно разбирали гарантию "точно 1 раз". Оказалось, опять миф! Никто ничего нам не гарантирует, и всё надо делать самим и ручками (никогда такого не было, и вот опять!). Это подстегнуло меня углубиться в эту тему, после чего я и пришла к вам.
Ранее мы разобрали механизм работы брокера, теперь свяжем этот механизм с гарантиями.

📩 At-least-once delivery: Дубликаты как неизбежность
Что обещают: Сообщение будет доставлено как минимум один раз.

Реальность: При сбоях (падение консьюмера, таймауты подтверждения) брокер отправит сообщение повторно. Результат - неизбежные дубликаты.

Почему:
1. Подтверждение (ack) может не дойти до брокера из-за сетевых проблем
2. Консьюмер может обработать сообщение, но упасть до отправки подтверждения



📩 At-most-once delivery: Потери как плата за скорость
Что обещают: Сообщение будет доставлено не более одного раза.

Реальность: Сообщения могут теряться при любых сбоях. Консьюмер подтверждает получение ДО обработки, поэтому при падении во время обработки сообщение теряется навсегда.

Где используется: В сценариях, где потеря данных менее критична, чем дублирование (например, метрики, логирование).


📩 Exactly-once semantics: Маркетинг или реальность?
Что обещают: Каждое сообщение будет обработано ровно один раз.

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

🆘 Проблемы exactly-once:
1. Огромные накладные расходы на производительность
2. Сложность реализации и отладки
3. Ограниченная поддержка в распределённых сценариях
4. Не защищает от логических ошибок в бизнес-коде


❗️Прежде чем выбирать этот вид, тщательно обоснуйте его выбор, убедитесь, что без него вы точно не можете!

Продолжаем тему ненадежности.
Начало было здесь

Самый надежный брокер бесполезен, если producer или consumer ненадежен. Именно на концах коммуникации - в точках производства и потребления сообщений - происходят самые коварные и сложные для отладки сбои.

Анатомия ненадежного consumer'а. Как все ломается


Сценарий катастрофы
Представьте consumer, который:
1. Получает сообщение из очереди
2. Начинает его обработку
3. Встречает временную ошибку (сеть, БД, внешний API)
4. Падает, не подтвердив обработку (не отправляет ack)
5. Сообщение возвращается в очередь
6. Процесс повторяется бесконечно

Результат: Очередь забита одним и тем же "битым" сообщением, система потребляет 100% CPU на бесполезную работу, новые сообщения не обрабатываются.

🆘 Корневые проблемы
1. "Зависшие" сообщения — сообщения, которые не могут быть обработаны, но и не могут быть отклонены окончательно

2. Бесконечные retry — циклические повторные попытки без прогресса

3. Забитые очереди — когда "мертвые" сообщения блокируют поток новых данных

Решения

✳️ Dead Letter Queue как система спасения
Dead Letter Queue - это специальная очередь для сообщений, которые не могут быть обработаны после исчерпания всех попыток или при установке наличия постоянной проблемыс данным сообщением. Как правило, такие сообщения требуют ручного разбора, поэтому эта очередь "обложена" событиями мониторинга.

Что класть в DLQ
1. Оригинальное сообщение полностью
2. Контекст ошибки (тип, сообщение)
3. Метаданные обработки (количество попыток, timestamp)
4. Заголовки из оригинального сообщения

Другие решения рассмотрим далее.

Как проектировать DLQ правильно (чек-лист)

Архитектура
🉑 DLQ на каждый consumer, а не одна общая «помойка».
🉑 Ограниченный retention с архивированием.
🉑 Версионирование схем сообщений.

Данные
🉑Полный payload.
🉑Структурированные error metadata.
🉑 Возможность трассировки через observability.


Автоматизация
☯️ Retry policy (exponential backoff)
☯️ Circuit breaker
☯️ Dead letter routing policy
☯️ Replay tool

Наблюдаемость
📎 Метрика размера DLQ
📎 Метрика скорости роста
📎 Топ ошибок по типам
📎 Alert при превышении порога

Зрелый взгляд на DLQ

На зрелом уровне DLQ — это:
- механизм изоляции «ядовитых» сообщений
- инструмент обнаружения регрессий
- индикатор проблем интеграции
- источник данных для улучшения схем и контрактов

Если DLQ растет — это не «операционная проблема».

Это сигнал о:
- нарушенном контракте
- деградации сервиса
- несовместимости версий,
- проблеме в бизнес-логике.

DLQ — это монитор качества событийной архитектуры.

И если к ней относиться как к мусорке — она станет мусоркой.
Если относиться как к инструменту отладки — она станет системой раннего предупреждения.

Кто должен обрабатывать DLQ

Антипаттерн:
«Если что-то упало — разработчики потом посмотрят».

Правильный подход:
DLQ — это часть бизнес-процесса, а не просто технический хвост.

Есть три сценария

1️⃣ Автоматический retry

Если ошибка временная, backoff + повторная публикация в основную очередь.

2️⃣ Полуавтоматический разбор
Сообщение требует исправления (неверный формат, неконсистентные данные, конфликт версий), то должен быть конкретный инструмент для:

- просмотра payload
- редактирования
- повторной отправки

3️⃣ Финальная утилизация
Сообщение невозможно обработать корректно.
Например, нарушена бизнес-логика.

DLQ должна иметь владельца (сотрудника или команду). Без владельца DLQ гарантированно зарастает.

Я пропустила знаменательный момент для любого канала и блога!

🎉🎉🎉🎉🎉🎉🎉
1️⃣0️⃣0️⃣
🎉🎉🎉🎉🎉🎉🎉

Рубеж в 100 подписчиков пройден! Цифра небольшая по меркам интернета. Но в системном дизайне мы знаем: важен не абсолютный масштаб, а архитектура и качество связей.
Мой канал - не про хайп. Он про вдумчивый разговор о системах.

Спасибо вам за интерес к сложным темам!
Дальше - больше глубины, больше практики. Работаем :)

Недавно большой интерес у коллег SRE вызвала DLQ. Разберем немного подробнее термины, которые упоминались ранее, и посмотрим на DLQ под другим углом.

🔻Механизм изоляции «ядовитых» сообщений

Ядовитым называют то сообщение, которое даже при многократных попытках обработки не может принести пользу Консьюмеру. Например, отсутствие обязательного поля ведет к тому, что будет падать при каждом ретрае и может блокировать очередь.
Лаг растет. Система деградирует. Занавес...

Под механизмом понимается логика: если N попыток обработки стали неуспешными - в DLQ. Проблема локализуется, система не стопорится.

🔻 Инструмент обнаружения регрессий и проблем интеграции

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

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

DLQ показывает не только технические ошибки.
Он показывает семантические конфликты между командами.

🧲 Как DLQ помогает улучшать схемы?

1. Поможет выявить неоднозначные поля (например, где нет четкого enum-списка или версий)

2. Выявит обязательные поля

3. Ошибки совместимости и версионирования

4. (на мой взгляд самый главный пункт) Дает повод проанализировать и улучшить retry-стратегию

Немного отойду от технической основы и поделюсь с вами своим наблюдением.

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

Вот какой самый главный инсайт я вынесла из ее выступления:
Иногда важно… поскучать.

С моей многоуровневой многозадачностью это утверждение мне очень откликнулось.
Я думаю, все собравшиеся здесь айтишники живут в режиме постоянной загрузки: рабочие задачи, уведомления, встречи по работе и личные, подкасты на фоне, развитие и статьи «впрок».
"Быть занятым" стало синонимом "быть продуктивным".

Но у сознания есть предел пропускной способности. Только в отличие от ИТ-систем здесь нет DLQ или алертов. Наша голова не уходит в отказ.
Просто внимание рассеивается, и мышление перестаёт быть глубоким. Оно становится реактивным.
Мы не думаем. Мы отвечаем.

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

Именно в моменты «ничего не происходит» мозг начинает перерабатывать накопленное. Парадоксально, но без периодов пустоты не появляется глубина.

Постоянная занятость создаёт иллюзию движения.
Скука создаёт пространство для смысла.

Это не потерянное время.
Это внутренний кэш, который очищается перед следующей нагрузкой.

Иногда лучший способ двигаться вперёд — на время остановиться...
Не забывайте об этом 🧡

Поставьте реакцию, если вам откликнулось

Следующее решение проблемы consumer'ов

✳️Интеллектуальный Retry с экспоненциальной задержкой
Со словом ретрай все понятно - повторы запросов.
А вот с экспоненциальностью разберемся. Действуем от обратного. Простой ретрай с фиксированным повтором (каждые N секунд):
⚛️ Не дает системе восстановиться
⚛️ Создает искусственную нагрузку
⚛️ Не учитывает природу ошибки

Лучше использовать увеличиваемая задержка + случайная добавка
⏺️ Категоризация ошибок: временные vs постоянные. Если временные (моргает сеть), то увеличиваем время ожидания между попытками. Если ошибка постоянная, то сразу отправляем в очередь dead

⏺️ Экспоненциальная задержка: 1s → 2s → 4s → 8s → 16s. позволяет не делать лавину запросов сразу после того,как сервис заработал.

⏺️ Случайная добавка: предотвращает синхронизацию множества consumer'ов, которые сразу набросятся со своими сообщениями, как только сервис восстановится. С добавкой поступление сообщение будет чутьболее равномерным.

⏺️ Максимальный лимит попыток: обычно 3-8 в зависимости от бизнес-логики

Следующее решение проблемы consumer'ов
Circuit Breaker (автоматический предохранитель)

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

Три состояния Circuit Breaker:

❎ Закрыт: Запросы проходят нормально. Если количество ошибок превышает порог, переключается в Open.
⭕️ Открыто: Запросы мгновенно отклоняются с ошибкой (fallback), не доходя до сервиса. Запускается таймер «окна сна».
🆚 Полуоткрыто: По истечении таймера позволяет пройти небольшому количеству тестовых запросов. Если они успешны, переключается в Closed. Если нет — возвращается в Open.

Решение конкретных проблем

🔰 «Зависшие» сообщения

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

Решения:

⚜️Timeout на уровне обработки
Установить таймауты на обработку сообщений. Если обработка длится дольше заданного лимита, прервать её выполнение и вернуть сообщение обратно в очередь с указанием причины отказа.


⚜️Сердцебиение
Периодически отправлять сигналы активности. Если потребитель долго не отправляет сигнал, считать его неактивным и освободить ресурсы.


🔰 Бесконечные retry

Симптомы:
Сообщение постоянно повторяется снова и снова, счётчик попыток растёт, однако прогресса в выполнении операции нет.

Решения

🔸Умный счетчик попыток
Реализовать экспоненциальную стратегию задержки между попытками (backoff). Например, удвоение интервала ожидания перед следующей попыткой. Ограничить максимальное число повторений.


🔸 Анализ ошибок
Регулярно анализировать журналы ошибок и предупреждать администратора системы о частых ошибках определённого типа. Это позволит оперативно выявить корневую причину проблемы.


🔰 Забитые очереди

Симптомы
Длина очереди быстро возрастает, латентность запросов значительно увеличивается, поступающие сообщения начинают задерживаться или вовсе теряться.

Решения

🔹 Мониторинг
Постоянно мониторить длину очередей и уровень загрузки потребителей. Использовать инструменты мониторинга вроде Prometheus, Grafana или New Relic.


🔹 Автоматическое масштабирование
Автоматизировать процесс добавления новых экземпляров consumers при увеличении нагрузки и удаления их при снижении трафика.


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

Хочешь прокачать системный анализ и архитектуру не на словах, а на практике? 🚀

Analyst Marathon #17 состоится уже 18 апреля!
Ребята собрали действительно полезный hard skills контент без “общих рассуждений” (впрочем, они всегда делают полезный контент):
🎾 как правильно делать записи архитектурных решений (ADR), чтобы ими реально пользовались
🎾 как создавать AI-ассистента и встроить его в процессы
🎾 как стандартизировать API, чтобы команды не страдали
🎾 и ещё много практики, которую можно применять сразу

Если вам важно не просто “знать”, а делать системы лучше, то вам точно сюда.

🎁 🎁 🎁 🎁
А для тех, кто дочитал до этого момента, ждет приятный сюрприз, и даже не один!

🎀 В эту пятницу 10 апреля в 13.30 я буду проводить розыгрыш бесплатного билета на Analyst Marathon #17

🎀 Организаторы конференции любят мой уютный канал, поэтому согласились в качестве бонуса на 4 дня (до 11 апреля 2026) открыть доступ к моему докладу с Analyst Marathon #16: «Практика гибридных архитектур: руководство для аналитика» Это идеальный «разогрев» перед конфой. Торопитесь его посмотреть: он припрятан в описании программы конференции.
Внутри:
🔹 Конец архитектурным холиварам: конкретная схема для выбора распределенных систем и реальный кейс, чтобы аргументированно защищать свои решения.
🔹 Чек-лист для старта: список вопросов, которые помогут принять верное решение для критических компонентов системы.
🔹 Умная декомпозиция: освоите принцип деления системы по скорости изменений и бизнес-рискам — лучший способ найти узкие места.
🔹 Инструкция к действию: пошаговый список шагов для создания устойчивой и гибкой архитектуры.


🎀 Конечно, для подписчиков всегда есть промокод на скидку 20%
🎁🎁 DB20_AM17 🎁🎁

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

Ну что, уже посмотрели мой доклад? Вдохновились перед конфой? Тогда переходим к главному: к розыгрышу билета.
🎈 Кто первым ответит на два вопроса - отдам билет
(отвечаем в комментариях к этому посту)

❓Вопросы

1. Если “ничего не сломалось” при дубле - это благодаря чему?
2. К чему может привести коммит offset'а до записи в БД?

Жду ваши ответы в комментарии!

А для тех, кто не успел, всегда есть промокод на скидку 20% 🎁 DB20_AM17 🎁
Программа и покупка билетов здесь

Хочу начать следующую тему, которая давно меня интересует.
🏮 Что такое "девятки" в надежности и почему о них все говорят 🏮

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

Доступность - это процент времени, в течение которого система работает и доступна пользователям.
Как измерить
availability = uptime / (uptime + downtime)
"Девятки" — это просто способ записать доступность:
99% → "две девятки"
99.9% → "три девятки"
99.99% → "четыре девятки"
99.999% → "пять девяток"
Звучит почти одинаково. Но разница - слишком большая.

Переведём это в реальное время простоя за год:
99% → ~3.6 дня
99.9% → ~8.7 часов
99.99% → ~52 минуты
99.999% → ~5 минут

Разница между 99.9% и 99.999% — это не "чуть лучше". Это переход от часов простоя к минутам в год.

🕶 Почему бизнес так любит «девятки»
Потому что простой стоит денег. Чем критичнее продукт, тем дороже каждая минута недоступности:
- онлайн-магазин теряет выручку
- платежная система — транзакции
- B2B-сервис — доверие клиентов и контракты

Поэтому появляются SLA (Service Level Agreement) — обещания доступности:
"99.9% uptime гарантирован"
"99.99% или компенсация"

Девятки становятся языком общения с клиентами и инструментом продаж.
Бизнес видит высокие цифры и чувствует себя спокойнее: Высокая доступность = меньше рисков = конкурентное преимущество.

Канал есть в MAX

♻️ Не вся "доступность" одинакова ♻️
Казалось бы ситуация бинарна: система упала - downtime, работает - uptime. Какие еще есть варианты?

Оказывается, оттенки есть и здесь. Можно считать:
- по времени (сервис не отвечает)
- по ошибкам (часть запросов падает)
- по пользователям (у кого-то работает, у кого-то нет)

Получается, 2 сервиса с 99.9% могут ощущаться совершенно по-разному.


♨️ Частичные сбои часто игнорируются
Система может работать медленно, отдавать ошибки 10% пользователей, ломать отдельные функции
Формально - аптайм есть.
Фактически - пользователь страдает.


⛓️‍💥 Окна обслуживания выпадают из статистики
Иногда плановые downtime не учитывается в SLA и выносится в технические окна
И тогда 99.99% на бумаге не равняются 99.99% в жизни.

🥎 "Пять девяток" — это редко про весь продукт
Часто это про конкретный компонент, отдельный API и вообще про идеальные условия существования сервиса (читай, никогда). Весь пользовательский путь end-to-end обычное не включается в "пять девяток".


Обычно инженеры относятся к "девяткам" осторожно, потому что за каждой дополнительной "девяткой" стоит:
- кратный рост сложности
- рост стоимости инфраструктуры
- рост требований к процессам

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

Канал есть в MAX

🕰 Про виды downtime'ов и как с ними жить или почувствуй себя немного SRE

Downtime бывает плановый (релизы) и аварийный.

🧧В понятие доступности нужно включать плановый downtime или нет?
Нужно. Ведь пользователю, который не может достучаться до сервиса неважна причина недоступности: инцидент или релиз.

🧧 Когда допустимо исключать плановый downtime из рассчитанной доступности?
Если предусмотрены строгие SLA-окна и система не обязана работать в указанное время (например, ночные окна обслуживания)

🧧 Где начинается манипуляция?
Там, где аварию можно прикрыть плановым downtime или вообще не считать событие downtime'ом. Т.е. когда релизы влекут за собой деградацию функционала, а оформляется как плановый. Или когда задержки выросли, но downtime не зафиксирован.

💌 Как решать?
1. Сделать 2 метрики: Общая доступность (с учетом всего) Операционная доступность (без плановой)
2. Учитывать деградации отдельно
3. 3. Сделать метрику с влиянием на пользователей

Канал есть в MAX

🧾 Как считать инциденты: время, пользователи или транзакции?

⏰ По времени
сервис был недоступен 30 минут → downtime = 30 минут
Нюансы:
- игнорируется масштаб 
- не учитывается частичная деградация

Пример: 1% запросов падает 24 часа → downtime по времени ≈ 0


🙍‍♂️По пользователям
Формула: доля пользователей, столкнувшихся с ошибками

Плюсы:
- ближе к реальному UX 
- учитывает частичные проблемы

Минусы:
- сложно считать 
- не учитывает интенсивность использования

⛓️ По транзакциям
Формула: Отношение успешных запросов ко всем запросам

Плюсы:
- точная 
- хорошо автоматизируется 
- чувствительна к деградациям

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


❓И как действовать?
Не можешь выбрать - бери всего по чуть-чуть:

🔑 Доступность (по времени) 
🔑 Показатель успешности (по транзакциям) 
🔑 Влияние (по пользователям)
И отдельно:
🗝 деградации (задержки, частичные сбои)

Главное❗️
не считать доступность "в вакууме", а привязывать её к реальному влиянию на пользователей и бизнес.

Коллеги SRE, что скажете?

Канал есть в MAX

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

Зачем вообще это всё?
Когда команда говорит "сервис работает нормально", это бессмысленно без измерений. SRE-подход вводит три уровня:

✳️ SLI (Service Level Indicator)
Это метрика качества. Это то, что мы измеряем:
- процент успешных запросов 
- latency (p95, p99) 
- uptime

✳️ SLO (Service Level Objective)
Это цель по метрике. Это то, насколько хорошо должно быть то, что мы измерили:
+ 99.9% успешных запросов за 30 дней 
+ p95 latency < 200ms

✳️ SLA (Service Level Agreement)
Это договор с пользователем о последствиях. Это то, что будет, если мы облажались
если доступность < 99.5% → компенсация

❇️ Error Budget
сколько ошибок допускаем
Например, на 1 млн запросов в месяц допускаем 0.1% = 1000 ошибок

❌ Не делайте SLO = 100%
✅ Связывайте SLO с бизнесом

Канал есть в MAX

Вышла 3я и последняя часть цикла статей про мифы REST

🧮 Как считать доступность в микросервисах

На первый взгляд: берём uptime каждого сервиса и радуемся:
- Service A: 99.9% 
- Service B: 99.9%
"Значит система тоже 99.9%" - скажем мы.
А вот и нет. В композиции сервисов действует другая математика.

🔗 Последовательная цепочка
Если запрос проходит через 3 сервиса (последовательная цепочка Client → API → Auth → DB), у каждого из которых 99.9%, то:

0.999 × 0.999 × 0.999 = 0.997 ≈ 99.7%

Цифра получилась меньше.
Формула для последовательной цепочки:

Availability_total = Π Availability(i)

⛓️ Параллельные запросы
Если запрос обрабатывается параллельными независимыми вызовами сервисов А и В (каждый по 99%), то:

1 - (1 - A)(1 - B) = 99.99%

Общая надежность получилась выше.

Канал есть в MAX