Merge Baltic
Продолжу тему впечатлений о конференциях.
Конференция бренда Merge "сложилась" для меня лишь со второй попытки. Первый мой доклад отклонили, после чего стало ясно: углубленное изучение технических деталей здесь не всегда интересно. Поэтому я решила сменить тактику и предложила более философски ориентированную тему — и вот тогда мое выступление вошло в официальную программу мероприятия.
Самое яркое впечатление произвело место проведения: Светлогорск, уютный город в живописнейшей Калининградской области. Эта территория сама по себе похожа на природный музей-заповедник, наполненный чудесами природы. К тому же мне повезло попасть сюда именно осенью, когда золотые краски листвы сделали атмосферу особенно чарующей.
Теперь поговорим непосредственно о самом событии.
Моя любимая привычка закапываться в сложные темы тут не сработала. Вместо узких технических вопросов я переключилась на общие, понятные и интересные как техническим специалистам, так и представителям бизнеса. Именно в этом и есть главная фишка конференции: объединить представителей разных сфер вокруг общих проблем и обсудить возможные пути их решения.
Особенно запомнился Руслан Сафин. Его глубокомысленные размышления об архитектурных принципах программного дизайна были настолько вдохновляющими, что вполне могли стать отдельной самостоятельной лекцией.
Резюмирую: эта конференция идеально подходит для знакомства с общей картиной индустрии разработки ПО, установления полезных контактов и поиска решений, интересных и разработчикам, и руководителям проектов, и менеджерам высшего звена.
Если охарактеризовать конфу одним словом — это дух «small talk»: непринужденные беседы и диалоги, формирующие живую интеллектуальную среду для всех участников.
Продолжу тему впечатлений о конференциях.
Конференция бренда Merge "сложилась" для меня лишь со второй попытки. Первый мой доклад отклонили, после чего стало ясно: углубленное изучение технических деталей здесь не всегда интересно. Поэтому я решила сменить тактику и предложила более философски ориентированную тему — и вот тогда мое выступление вошло в официальную программу мероприятия.
Самое яркое впечатление произвело место проведения: Светлогорск, уютный город в живописнейшей Калининградской области. Эта территория сама по себе похожа на природный музей-заповедник, наполненный чудесами природы. К тому же мне повезло попасть сюда именно осенью, когда золотые краски листвы сделали атмосферу особенно чарующей.
Теперь поговорим непосредственно о самом событии.
Моя любимая привычка закапываться в сложные темы тут не сработала. Вместо узких технических вопросов я переключилась на общие, понятные и интересные как техническим специалистам, так и представителям бизнеса. Именно в этом и есть главная фишка конференции: объединить представителей разных сфер вокруг общих проблем и обсудить возможные пути их решения.
Особенно запомнился Руслан Сафин. Его глубокомысленные размышления об архитектурных принципах программного дизайна были настолько вдохновляющими, что вполне могли стать отдельной самостоятельной лекцией.
Резюмирую: эта конференция идеально подходит для знакомства с общей картиной индустрии разработки ПО, установления полезных контактов и поиска решений, интересных и разработчикам, и руководителям проектов, и менеджерам высшего звена.
Если охарактеризовать конфу одним словом — это дух «small talk»: непринужденные беседы и диалоги, формирующие живую интеллектуальную среду для всех участников.
Переходим к следующему мифу.
⚓️ Когда eventual consistency — это не про данные, а про бизнес-процессы
Моя "любимая" согласованность... в кавычках, потому что, мне кажется, я на своих докладах всем вынесла мозг с ней. Рассмотрим очередную ее грань...
Асинхронность часто связана с eventual consistency: данные рано или поздно синхронизируются. Это звучит безобидно — пока не проявляется в пользовательских сценариях...
Пример: заказ создан, но платёж «где-то едет»
Пусть пользователь оформляет заказ. Фронтенд получает успешный ответ: «Заказ создан». Через секунду он открывает историю заказов — а там заказа нет, потому что поток обработки платежей задержался, и сервис заказа пока не обновил статус.
Что думает пользователь?
«Сайт сломался, надо оформлять заново». Даже если бизнес-процесс формально корректен, пользователь все равно идет оформлять повторно.
Вот что стоит помнить:
🎲 Eventual consistency — это не только про репликацию данных.
Это про рассинхронизацию реальности и того, что видит пользователь!! Поэтому асинхронность вынуждает продумывать UX иначе.
🎲 Нужно объяснять пользователю, что происходит: «Платеж обрабатывается…». А это означает изменения интерфейса, API, состояния в БД, SLA на задержки.
🎲 Асинхронная архитектура = асинхронный бизнес.
🎲 Процессы меняются: появляется потребность в сагах, компенсационных транзакциях, промежуточных состояниях.
Иными словами, внедряя асинхронность, вы меняете не только технологию, но и то, как бизнес работает с реальностью.
Казалось бы, очевидное утверждение. Но оно не всегда вспоминается при проектировании. Поэтому призываю вас ❗️ сделать это утверждение своей парадигмой, когда вы проектируете асинхронные процессы.
⚓️ Когда eventual consistency — это не про данные, а про бизнес-процессы
Моя "любимая" согласованность... в кавычках, потому что, мне кажется, я на своих докладах всем вынесла мозг с ней. Рассмотрим очередную ее грань...
Асинхронность часто связана с eventual consistency: данные рано или поздно синхронизируются. Это звучит безобидно — пока не проявляется в пользовательских сценариях...
Пример: заказ создан, но платёж «где-то едет»
Пусть пользователь оформляет заказ. Фронтенд получает успешный ответ: «Заказ создан». Через секунду он открывает историю заказов — а там заказа нет, потому что поток обработки платежей задержался, и сервис заказа пока не обновил статус.
Что думает пользователь?
«Сайт сломался, надо оформлять заново». Даже если бизнес-процесс формально корректен, пользователь все равно идет оформлять повторно.
Вот что стоит помнить:
🎲 Eventual consistency — это не только про репликацию данных.
Это про рассинхронизацию реальности и того, что видит пользователь!! Поэтому асинхронность вынуждает продумывать UX иначе.
🎲 Нужно объяснять пользователю, что происходит: «Платеж обрабатывается…». А это означает изменения интерфейса, API, состояния в БД, SLA на задержки.
🎲 Асинхронная архитектура = асинхронный бизнес.
🎲 Процессы меняются: появляется потребность в сагах, компенсационных транзакциях, промежуточных состояниях.
Иными словами, внедряя асинхронность, вы меняете не только технологию, но и то, как бизнес работает с реальностью.
Казалось бы, очевидное утверждение. Но оно не всегда вспоминается при проектировании. Поэтому призываю вас ❗️ сделать это утверждение своей парадигмой, когда вы проектируете асинхронные процессы.
Analyst Days
Финальная конференция сезона и знаковое событие в мире аналитики — AnalystDays. Давно мечтала посетить её лично, и вот, наконец, моя мечта сбылась именно в этот год!
Особенно приятно осознавать, что хотя конференция ориентирована исключительно на системный и бизнес-анализ, ей удаётся сохранить впечатляющий размах и привлечь огромное количество профи. Только спикеров в этом году больше сотни!
Для меня важным показателем уровня мероприятия является тяжелый выбор, на какой доклад пойти, тк сразу несколько интересных тем рассматривается одновременно. Такое со мной случается не на каждой конфе.
Несмотря на масштаб, атмосфера остаётся дружелюбной и располагающей к нетворкингу. Можно легко найти собеседника по любой интересующей теме, включая идеи будущих докладов с программным комитетом.
Отдельного восхищения заслужило афтепати. Танцы помогают разрядить обстановку и снизить серьёзность, что способствует более неформальному общению среди участников. Я думаю, дискотека должна стать обязательным элементом афтепати каждой крупной конференции. Согласны?
Уже сейчас начинаю подготовку к новому сезону и активно собираю свежие мысли и идеи. Очень надеюсь на вашу помощь и поддержку: расскажите о направлениях, которые вам интересны.
Как вызнаете, я люблю практические кейсы и конкретные решения конкретных проблем, поэтому сухие мотивационные лекции вроде "как оставаться в ресурсе" меня ещё не зацепили. Если у вас есть интересные задачки, буду рада ознакомиться с вашими мыслями.
Финальная конференция сезона и знаковое событие в мире аналитики — AnalystDays. Давно мечтала посетить её лично, и вот, наконец, моя мечта сбылась именно в этот год!
Особенно приятно осознавать, что хотя конференция ориентирована исключительно на системный и бизнес-анализ, ей удаётся сохранить впечатляющий размах и привлечь огромное количество профи. Только спикеров в этом году больше сотни!
Для меня важным показателем уровня мероприятия является тяжелый выбор, на какой доклад пойти, тк сразу несколько интересных тем рассматривается одновременно. Такое со мной случается не на каждой конфе.
Несмотря на масштаб, атмосфера остаётся дружелюбной и располагающей к нетворкингу. Можно легко найти собеседника по любой интересующей теме, включая идеи будущих докладов с программным комитетом.
Отдельного восхищения заслужило афтепати. Танцы помогают разрядить обстановку и снизить серьёзность, что способствует более неформальному общению среди участников. Я думаю, дискотека должна стать обязательным элементом афтепати каждой крупной конференции. Согласны?
Уже сейчас начинаю подготовку к новому сезону и активно собираю свежие мысли и идеи. Очень надеюсь на вашу помощь и поддержку: расскажите о направлениях, которые вам интересны.
Как вызнаете, я люблю практические кейсы и конкретные решения конкретных проблем, поэтому сухие мотивационные лекции вроде "как оставаться в ресурсе" меня ещё не зацепили. Если у вас есть интересные задачки, буду рада ознакомиться с вашими мыслями.
Привет всем! 👋
Пока все втягиваются в рабочий ритм, хочу поделиться одним маленьким, но (как теперь выяснилось) волшебным лайфхаком. Кажется, он спасает от всего.
Встречайте — Его Величество Цифровой Детокс. Что-то новое? Нет, конечно. Но мы, вечно спешащие и уставшие жители мегаполисов, его силу явно недооцениваем. Давайте я вас немного подтолкну в эту сторону. 😉
А для понимания масштаба катастрофы, расскажу, с чем я подошла к старту (работу в список не включаю — это и так понятно):
1. Шёл третий год материнства. На этом список можно было бы и закончить, но я продолжу.
2. Материнство — это четверть «беды». Активная мама — ещё четверть. Я таскала ребёнка везде с собой, а когда она подросла и заинтересовалась — мы ходим на все детские мероприятия города. Контроль над их количеством был безвозвратно утерян.
3. Летом ребёнок научился оставаться без меня больше суток, и тут Остапа понесло... Я так рьяно бросилась навёрстывать три года «упущенной свободы», что окружающих мой график начал пугать сразу, а меня — только к концу года. Сначала было 10 событий в квартал, потом — за два месяца, а в декабре я насчитала 17 мероприятий (из них 9 детских!),где требовалось моё участие и подготовка!. Семья шептала: «Остановись!», а съезжающая кукуха сыпала предложениями: «А давай ещё вот это придумаем!».
4. Еще четверть "беды" - это проекты, в которые я иногда вписываюсь просто потому что мне интересно. Это тоже время и затрачиваемая энергия, хоть и "по любви"
5. Кажется, четыре четверти — это уже целое, а значит пятого пункта уже быть не должно. Но я перевалила даже за него и добавила профессиональное развитие, в которое погрузилась с головой. Тянет на добрую треть, не меньше.
Итог: 1 целая и 1/3 «беды». Голова дымится, усталость накапливается, а концентрация — где-то потерялась и не хочет возвращаться.
Пока все втягиваются в рабочий ритм, хочу поделиться одним маленьким, но (как теперь выяснилось) волшебным лайфхаком. Кажется, он спасает от всего.
Встречайте — Его Величество Цифровой Детокс. Что-то новое? Нет, конечно. Но мы, вечно спешащие и уставшие жители мегаполисов, его силу явно недооцениваем. Давайте я вас немного подтолкну в эту сторону. 😉
А для понимания масштаба катастрофы, расскажу, с чем я подошла к старту (работу в список не включаю — это и так понятно):
1. Шёл третий год материнства. На этом список можно было бы и закончить, но я продолжу.
2. Материнство — это четверть «беды». Активная мама — ещё четверть. Я таскала ребёнка везде с собой, а когда она подросла и заинтересовалась — мы ходим на все детские мероприятия города. Контроль над их количеством был безвозвратно утерян.
3. Летом ребёнок научился оставаться без меня больше суток, и тут Остапа понесло... Я так рьяно бросилась навёрстывать три года «упущенной свободы», что окружающих мой график начал пугать сразу, а меня — только к концу года. Сначала было 10 событий в квартал, потом — за два месяца, а в декабре я насчитала 17 мероприятий (из них 9 детских!),где требовалось моё участие и подготовка!. Семья шептала: «Остановись!», а съезжающая кукуха сыпала предложениями: «А давай ещё вот это придумаем!».
4. Еще четверть "беды" - это проекты, в которые я иногда вписываюсь просто потому что мне интересно. Это тоже время и затрачиваемая энергия, хоть и "по любви"
5. Кажется, четыре четверти — это уже целое, а значит пятого пункта уже быть не должно. Но я перевалила даже за него и добавила профессиональное развитие, в которое погрузилась с головой. Тянет на добрую треть, не меньше.
Итог: 1 целая и 1/3 «беды». Голова дымится, усталость накапливается, а концентрация — где-то потерялась и не хочет возвращаться.
Планируемое лечение
30 декабря, когда я закрыла рабочий ноутбук, в голове щёлкнуло: впереди не просто праздники. Впереди 12 дней, когда гарантированно отдыхают абсолютно все. А это волшебное окно, когда ни одна из моих «четвертей беды» не станет меня искать. Это ключевое отличие от обычного отпуска, когда что-то где-то случается и нужно «просто на минутку» подключиться, убивая весь эффект отдыха.
Решение созрело: полный цифровой детокс. Отрекаюсь от соцсетей, маркетплейсов и любых напрягающих контактов. Общение — только с самыми близкими. Телефон — только по делу.
Честно, такой эксперимент я проводила лишь раз в жизни, ещё студенткой. Тогда это казалось роскошью. Сейчас — необходимостью.
Реализация замысла
Дни 1-3: Палец на автопилоте трижды тянулся к иконке соцсети и успевал тапнуть, прежде чем мозг протестовал. Я сразу выходила, так что не считается! 😅
Книги! Я и так читаю перед сном, но тут... 2 большие книги за 12 дней! (Разумеется, ребёнок был у бабушки — без этого чуда бы не случилось). Это было восхитительное погружение, как в доматеринские времена.
«Потом почитать»: В браузерах накопилась гигантская (штук 20, для меня это много!) коллекция вкладок, покрытых цифровой пылью. И знаете что? Я до них добралась. Просто потому, что больше не было, куда спешить.
Итог
1. Я счастлива. Без лишних слов.
2. Голова не просто очистилась — она замедлилась. С моим темпом жизни это ощущается как ледяной душ посреди жаркого дня. Невероятная ясность.
3. Исчезло «рваное внимание». Помню из курса по ОС, что переключение контекста для процессора часто дороже самой операции. Наш мозг — та же система. Когда его не дёргают каждые пять минут, он начинает работать качественнее.
Что теперь (или главный инсайт)
Вернувшись в рабочие будни, я не почувствовала того привычного ужаса перед шквалом задач. Дело в другом: я теперь внимательнее отношусь к тому, что именно беру в голову. Прежде чем вписать новую активность в график, я на секунду задумываюсь: «А какой урон это нанесёт тому хрупкому спокойствию, которое сейчас царит у меня внутри?». И это, пожалуй, самый ценный вывод из всего эксперимента.
Что хочу порекомендовать
1. Если в отпуске есть возможность отключить телефон или соцсети — сделайте это! Рука тянется только первые три дня. Перетерпите, и уже через неделю вы себе скажете спасибо.
2. Даже если возможности нет — зафиксируйте в памяти это состояние «обнуления» после отдыха. Когда на вас обрушится шквал задач по возвращении, это чувство поможет продлить эффект отдохнувшей головы.
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 поверх брокера и его ловушки
Брокер как единая точка отказа: миф о магической отказоустойчивости
Широко распространён миф: «Сделаем через очереди - и система станет устойчивее». Но брокер - это такой же критический компонент, как база данных. Иногда даже более критический: возможность передать событие - это кровеносная система архитектуры.
❓Что происходит при падении брокера?
🔸Продюсеры не могут отправлять сообщения. Бизнес замирает
Если продюсер не может опубликовать событие о завершении заказа, оплате или изменении данных, бизнес-процесс останавливается на самом старте.
Решение: outbox паттерн
Когда Продюсер публикует сообщение напрямую в брокер в рамках бизнес-транзакции - это считается плохим тоном. Вместо этого в рамках той же транзакции с БД, запись о событии сохраняется в специальную таблицу outbox в локальной базе данных сервиса. Это гарантирует атомарность: либо бизнес-данные и событие сохранены, либо нет. Отдельный, легковесный процесс забирает записи из outbox и отправляет их в брокер. Если брокер недоступен, процесс ждет и повторяет попытки с настроенной задержкой. Событие будет доставлено, когда это станет возможным.
В моей практике бывали случаи, когда эту outbox-таблицу приходилось разбирать руками, когда брокер больше 6 часов не мог забрать данные. Но это скорее исключение.
🔸 Консьюмеры перестают получать сообщения. Фоновые задачи умирают
Сервис-консьюмер, обрабатывающий уведомления или обновляющий кэши, становится бесполезным. Накопление очереди — это меньшее зло, чем полная остановка обработки.
Решение: Стратегия «Живучего консьюмера»
▪️Health Checks и Circuit Breaker: Консьюмер должен предоставлять строгий эндпоинт здоровья (/health), который проверяет не только его процесс, но и соединение с брокером и состояние потребления. Оркестратор (как правило, Кубер) должен рестартовать узел при проблемах.
▪️ Контрольные точки во внешнем хранилище: Не полагайтесь только на встроенный механизм коммитов брокера. Для критических задач периодически сохраняйте позицию обработки (ее еще называют смещением) в надежное, возможно, даже локальное дисковое хранилище. Это позволяет после сбоя начать не с последнего коммита в брокере (который мог быть потерян), а с известной безопасной точки.
▪️Изоляция обработки от потребления: Используйте паттерн «Конкурентный консьюмер» с внутренней очередью. Один поток читает из брокера и складывает сообщения во внутреннюю in-memory очередь (с лимитом), а пул рабочих потоков их обрабатывает. Падение брокера остановит только поток-читатель, а обработка текущих задач завершится.
...Асинхронность даёт новые формы отказов, а не избавляет от них.
Telegram
Мастерская IT-решений
Переходим к следующему мифу.
⚓️ Когда eventual consistency — это не про данные, а про бизнес-процессы
Моя "любимая" согласованность... в кавычках, потому что, мне кажется, я на своих докладах всем вынесла мозг с ней. Рассмотрим очередную ее грань...
Асинхронность…
⚓️ Когда eventual consistency — это не про данные, а про бизнес-процессы
Моя "любимая" согласованность... в кавычках, потому что, мне кажется, я на своих докладах всем вынесла мозг с ней. Рассмотрим очередную ее грань...
Асинхронность…
Продолжаем тему проблем Брокера. Предыдущие части
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. Это делает ожидание явным и управляемым. Это самый распространенный паттерн при генерации отчетов
Брокер, не болей! :)
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. Это делает ожидание явным и управляемым. Это самый распространенный паттерн при генерации отчетов
Брокер, не болей! :)
Telegram
Мастерская IT-решений
Переходим к следующему мифу.
⚓️ Когда eventual consistency — это не про данные, а про бизнес-процессы
Моя "любимая" согласованность... в кавычках, потому что, мне кажется, я на своих докладах всем вынесла мозг с ней. Рассмотрим очередную ее грань...
Асинхронность…
⚓️ Когда eventual consistency — это не про данные, а про бизнес-процессы
Моя "любимая" согласованность... в кавычках, потому что, мне кажется, я на своих докладах всем вынесла мозг с ней. Рассмотрим очередную ее грань...
Асинхронность…
Привет, друзья!
Хочу рассказать о классной онлайн-конференции для Системных аналитиков
🖤 Analyst Marathon 16 🖤
📅 7 февраля 2026 📅
будем усиленно обсуждать вопросы архитектуры, интеграции, безопасности и инструментов разработки. 80% спикеров знаю лично и совершенно точно могу рекомендовать доклад каждого из них.
Вы узнаете:
💟 Как грамотно выбирать гибридные архитектуры и эффективно интегрироваться с асинхронными системами.
💟 Какие методы и практики необходимы для безопасной работы с API и обработки данных.
💟 Современные подходы к созданию сервисов и платформ, включая работу с искусственным интеллектом и low-code инструментами.
Купить билет можно здесь
🎉 А я разыгрываю 1 бесплатный билет. Первый, кто в комментариях к этому посту ответит правильно на оба вопроса, получит промокод на билет. Вопросы, конечно, связаны с темой, которую разбирали последней
Вопросы:
1. Что может произойти с брокером, если потребитель будет обрабатывать сообщения медленнее, чем продюсер их отправляет?
2. Как называется основная единица хранения данных в Apache Kafka, внутри которой сообщения упорядочены и неизменяемы?
Хочу рассказать о классной онлайн-конференции для Системных аналитиков
🖤 Analyst Marathon 16 🖤
📅 7 февраля 2026 📅
будем усиленно обсуждать вопросы архитектуры, интеграции, безопасности и инструментов разработки. 80% спикеров знаю лично и совершенно точно могу рекомендовать доклад каждого из них.
Вы узнаете:
💟 Как грамотно выбирать гибридные архитектуры и эффективно интегрироваться с асинхронными системами.
💟 Какие методы и практики необходимы для безопасной работы с API и обработки данных.
💟 Современные подходы к созданию сервисов и платформ, включая работу с искусственным интеллектом и low-code инструментами.
Купить билет можно здесь
🎉 А я разыгрываю 1 бесплатный билет. Первый, кто в комментариях к этому посту ответит правильно на оба вопроса, получит промокод на билет. Вопросы, конечно, связаны с темой, которую разбирали последней
Вопросы:
1. Что может произойти с брокером, если потребитель будет обрабатывать сообщения медленнее, чем продюсер их отправляет?
2. Как называется основная единица хранения данных в Apache Kafka, внутри которой сообщения упорядочены и неизменяемы?
analyst-marathon.timepad.ru
Analyst Marathon #16. Интеграции, API, Микросервисы, Архитектурные подходы, Вайбкодинг, АI агенты и хранилища данных в работе BA/SA.…
Проектирование архитектуры ИС микросервисы и монолит, API, продвинутые интеграционные паттерны, брокеры, REST, НФТ, все про аутентификацию, вайбкодинг для аналитика, AI агенты и N8N и немного о работе с данными в ETL. Все что нужно в работе BA/SA от безусловно…
Механизм работы Брокера
Тема гарантий доставок является для меня животрепещущей, не терпится о ней порассуждать. Но для более глубокого понимания процесса следует разобрать базу: как вообще работает брокер.
✏️ - Продюсер
📖 - Читатель
📬 - Брокер
Шаг 1. Публикация
1. ✏️Продюсер устанавливает соединение с 📬Брокером (по протоколу AMQP, MQTT и тд).
2. ✏️Продюсер публикует сообщение в определённый топик (для Kafka).
3. 📬Брокер принимает сообщение и немедленно подтверждает его получение отправителю (это важно для гарантий). Если подтверждение не пришло, ✏️Продюсер может отправить сообщение повторно.
4. 📬Брокер сохраняет сообщение в памяти или на диск (в зависимости от настроек durability).
Шаг 2. Маршрутизация
1. Внутри топика по заранее заданным правилам определяет, в какие очереди должно быть помещено это сообщение.
2. Сообщение помещается в хвост выбранных очередей. Очередь - это и есть место хранения сообщений, ожидающих обработки.
Шаг 3: Доставка потребителю
1. 📖 Читатель, который заранее подписался на очередь, находится в состоянии ожидания.
2. Как только в очереди появляется сообщение, 📬Брокер выталкивает (push-модель, как в RabbitMQ) или позволяет забрать (pull-модель, как в Kafka) это сообщение 📖 Читателю.
3. Ключевой момент: После успешной обработки сообщения 📖 Читатель отправляет 📬 брокеру подтверждение (ACK).
4. Только после получения ACK 📬Брокер окончательно удаляет сообщение из очереди. Если ACK не пришло (consumer упал, таймаут), 📬Брокер считает доставку неудачной и перепосылает сообщение (другому или тому же потребителю).
Шаг 4: Обработка сбоев (на механическом уровне)
• Потеря соединения с 📖 Читателем: 📬Брокер возвращает неподтверждённые (unacked) сообщения обратно в очередь.
• Перезапуск 📬Брокера : Сообщения, объявленные как persistent (постоянные), восстанавливаются с диска.
• Недоступность 📖 Читателей: Сообщения накапливаются в очереди, пока не появится активный потребитель.
Чуть-чуть о гарантиях, чтобы вписать их в контекст
1. Подтверждение от брокера: Гарантия, что сообщение достигло брокера.
2. Сохранение на диск: Гарантия, что сообщение переживёт перезапуск брокера.
3. Подтверждение от потребителя: Гарантия, что сообщение было успешно обработано и может быть удалено. Без ACK — перепосылка.
4. Транзакции/Exactly-Once: Более сложные механизмы
Тема гарантий доставок является для меня животрепещущей, не терпится о ней порассуждать. Но для более глубокого понимания процесса следует разобрать базу: как вообще работает брокер.
✏️ - Продюсер
📖 - Читатель
📬 - Брокер
Шаг 1. Публикация
1. ✏️Продюсер устанавливает соединение с 📬Брокером (по протоколу AMQP, MQTT и тд).
2. ✏️Продюсер публикует сообщение в определённый топик (для Kafka).
3. 📬Брокер принимает сообщение и немедленно подтверждает его получение отправителю (это важно для гарантий). Если подтверждение не пришло, ✏️Продюсер может отправить сообщение повторно.
4. 📬Брокер сохраняет сообщение в памяти или на диск (в зависимости от настроек durability).
Шаг 2. Маршрутизация
1. Внутри топика по заранее заданным правилам определяет, в какие очереди должно быть помещено это сообщение.
2. Сообщение помещается в хвост выбранных очередей. Очередь - это и есть место хранения сообщений, ожидающих обработки.
Шаг 3: Доставка потребителю
1. 📖 Читатель, который заранее подписался на очередь, находится в состоянии ожидания.
2. Как только в очереди появляется сообщение, 📬Брокер выталкивает (push-модель, как в RabbitMQ) или позволяет забрать (pull-модель, как в Kafka) это сообщение 📖 Читателю.
3. Ключевой момент: После успешной обработки сообщения 📖 Читатель отправляет 📬 брокеру подтверждение (ACK).
4. Только после получения ACK 📬Брокер окончательно удаляет сообщение из очереди. Если ACK не пришло (consumer упал, таймаут), 📬Брокер считает доставку неудачной и перепосылает сообщение (другому или тому же потребителю).
Шаг 4: Обработка сбоев (на механическом уровне)
• Потеря соединения с 📖 Читателем: 📬Брокер возвращает неподтверждённые (unacked) сообщения обратно в очередь.
• Перезапуск 📬Брокера : Сообщения, объявленные как persistent (постоянные), восстанавливаются с диска.
• Недоступность 📖 Читателей: Сообщения накапливаются в очереди, пока не появится активный потребитель.
Чуть-чуть о гарантиях, чтобы вписать их в контекст
1. Подтверждение от брокера: Гарантия, что сообщение достигло брокера.
2. Сохранение на диск: Гарантия, что сообщение переживёт перезапуск брокера.
3. Подтверждение от потребителя: Гарантия, что сообщение было успешно обработано и может быть удалено. Без ACK — перепосылка.
4. Транзакции/Exactly-Once: Более сложные механизмы
А вот теперь о вкусном....
🔆 Ненадёжность «надёжных» доставок: идемпотентность как единственный реальный гарант
привет и спасибо, Андрей Бураков! :)
На своих воркшопах Андрей всегда погружает участников на те низкоуровневые операции над которыми ты сам обычно не задумываешься. На одном из таких воркшопов подробно разбирали гарантию "точно 1 раз". Оказалось, опять миф! Никто ничего нам не гарантирует, и всё надо делать самим и ручками (никогда такого не было, и вот опять!). Это подстегнуло меня углубиться в эту тему, после чего я и пришла к вам.
Ранее мы разобрали механизм работы брокера, теперь свяжем этот механизм с гарантиями.
📩 At-least-once delivery: Дубликаты как неизбежность
Что обещают: Сообщение будет доставлено как минимум один раз.
Реальность: При сбоях (падение консьюмера, таймауты подтверждения) брокер отправит сообщение повторно. Результат - неизбежные дубликаты.
Почему:
1. Подтверждение (ack) может не дойти до брокера из-за сетевых проблем
2. Консьюмер может обработать сообщение, но упасть до отправки подтверждения
📩 At-most-once delivery: Потери как плата за скорость
Что обещают: Сообщение будет доставлено не более одного раза.
Реальность: Сообщения могут теряться при любых сбоях. Консьюмер подтверждает получение ДО обработки, поэтому при падении во время обработки сообщение теряется навсегда.
Где используется: В сценариях, где потеря данных менее критична, чем дублирование (например, метрики, логирование).
📩 Exactly-once semantics: Маркетинг или реальность?
Что обещают: Каждое сообщение будет обработано ровно один раз.
Реальность: На практике это сложная комбинация нескольких факторов:
- Идемпотентность производителя - предотвращение дублирования отправки
- Транзакционные операции между потреблением и отправкой новых сообщений
- Идемпотентность консьюмера - ключевой элемент. Именно на потребителя вешается основная логика, поэтому гарантии брокера тут абсолютно вторичны. Это стало главным инсайтом для меня.
🆘 Проблемы exactly-once:
1. Огромные накладные расходы на производительность
2. Сложность реализации и отладки
3. Ограниченная поддержка в распределённых сценариях
4. Не защищает от логических ошибок в бизнес-коде
❗️Прежде чем выбирать этот вид, тщательно обоснуйте его выбор, убедитесь, что без него вы точно не можете!
🔆 Ненадёжность «надёжных» доставок: идемпотентность как единственный реальный гарант
привет и спасибо, Андрей Бураков! :)
На своих воркшопах Андрей всегда погружает участников на те низкоуровневые операции над которыми ты сам обычно не задумываешься. На одном из таких воркшопов подробно разбирали гарантию "точно 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. Заголовки из оригинального сообщения
Другие решения рассмотрим далее.
Начало было здесь
Самый надежный брокер бесполезен, если 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. Заголовки из оригинального сообщения
Другие решения рассмотрим далее.
Telegram
Мастерская IT-решений
А вот теперь о вкусном....
🔆 Ненадёжность «надёжных» доставок: идемпотентность как единственный реальный гарант
привет и спасибо, Андрей Бураков! :)
На своих воркшопах Андрей всегда погружает участников на те низкоуровневые операции над которыми ты сам…
🔆 Ненадёжность «надёжных» доставок: идемпотентность как единственный реальный гарант
привет и спасибо, Андрей Бураков! :)
На своих воркшопах Андрей всегда погружает участников на те низкоуровневые операции над которыми ты сам…
🔥1💯1
Как проектировать 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 на каждый 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 гарантированно зарастает.
Антипаттерн:
«Если что-то упало — разработчики потом посмотрят».
Правильный подход:
DLQ — это часть бизнес-процесса, а не просто технический хвост.
Есть три сценария
1️⃣ Автоматический retry
Если ошибка временная, backoff + повторная публикация в основную очередь.
2️⃣ Полуавтоматический разбор
Сообщение требует исправления (неверный формат, неконсистентные данные, конфликт версий), то должен быть конкретный инструмент для:
- просмотра payload
- редактирования
- повторной отправки
3️⃣ Финальная утилизация
Сообщение невозможно обработать корректно.
Например, нарушена бизнес-логика.
DLQ должна иметь владельца (сотрудника или команду). Без владельца DLQ гарантированно зарастает.
Я пропустила знаменательный момент для любого канала и блога!
🎉🎉🎉🎉🎉🎉🎉
1️⃣0️⃣0️⃣
🎉🎉🎉🎉🎉🎉🎉
Рубеж в 100 подписчиков пройден! Цифра небольшая по меркам интернета. Но в системном дизайне мы знаем: важен не абсолютный масштаб, а архитектура и качество связей.
Мой канал - не про хайп. Он про вдумчивый разговор о системах.
Спасибо вам за интерес к сложным темам!
Дальше - больше глубины, больше практики. Работаем :)
🎉🎉🎉🎉🎉🎉🎉
1️⃣0️⃣0️⃣
🎉🎉🎉🎉🎉🎉🎉
Рубеж в 100 подписчиков пройден! Цифра небольшая по меркам интернета. Но в системном дизайне мы знаем: важен не абсолютный масштаб, а архитектура и качество связей.
Мой канал - не про хайп. Он про вдумчивый разговор о системах.
Спасибо вам за интерес к сложным темам!
Дальше - больше глубины, больше практики. Работаем :)
❤3👏1
Недавно большой интерес у коллег SRE вызвала DLQ. Разберем немного подробнее термины, которые упоминались ранее, и посмотрим на DLQ под другим углом.
🔻Механизм изоляции «ядовитых» сообщений
Ядовитым называют то сообщение, которое даже при многократных попытках обработки не может принести пользу Консьюмеру. Например, отсутствие обязательного поля ведет к тому, что будет падать при каждом ретрае и может блокировать очередь.
Лаг растет. Система деградирует. Занавес...
Под механизмом понимается логика: если N попыток обработки стали неуспешными - в DLQ. Проблема локализуется, система не стопорится.
🔻 Инструмент обнаружения регрессий и проблем интеграции
Всем знакомо слово регресс и регрессионное тестирование. Представьте, что вы обновили сервис, и вдруг старые продюсеры начинают присылать сообщения, которые новый код не понимает.
И если DLQ разрослась и ошибки однотипные, то DLQ становится первым сигналом нарушения контракта. Поэтому вешайте на DQL анализ типов ошибок и алерт на рост.
DLQ показывает не только технические ошибки.
Он показывает семантические конфликты между командами.
🧲 Как DLQ помогает улучшать схемы?
1. Поможет выявить неоднозначные поля (например, где нет четкого enum-списка или версий)
2. Выявит обязательные поля
3. Ошибки совместимости и версионирования
4. (на мой взгляд самый главный пункт) Дает повод проанализировать и улучшить retry-стратегию
🔻Механизм изоляции «ядовитых» сообщений
Ядовитым называют то сообщение, которое даже при многократных попытках обработки не может принести пользу Консьюмеру. Например, отсутствие обязательного поля ведет к тому, что будет падать при каждом ретрае и может блокировать очередь.
Лаг растет. Система деградирует. Занавес...
Под механизмом понимается логика: если N попыток обработки стали неуспешными - в DLQ. Проблема локализуется, система не стопорится.
🔻 Инструмент обнаружения регрессий и проблем интеграции
Всем знакомо слово регресс и регрессионное тестирование. Представьте, что вы обновили сервис, и вдруг старые продюсеры начинают присылать сообщения, которые новый код не понимает.
И если DLQ разрослась и ошибки однотипные, то DLQ становится первым сигналом нарушения контракта. Поэтому вешайте на DQL анализ типов ошибок и алерт на рост.
DLQ показывает не только технические ошибки.
Он показывает семантические конфликты между командами.
🧲 Как DLQ помогает улучшать схемы?
1. Поможет выявить неоднозначные поля (например, где нет четкого enum-списка или версий)
2. Выявит обязательные поля
3. Ошибки совместимости и версионирования
4. (на мой взгляд самый главный пункт) Дает повод проанализировать и улучшить retry-стратегию
Forwarded from ИТ ПСБ
Готовы «нырнуть» глубже в тему заблуждений? В новой статье на Хабре разберем тонкости работы с методами, поговорим о настоящем смысле stateless и выясним, правда ли, что новые технологии отправляют REST на покой.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Немного отойду от технической основы и поделюсь с вами своим наблюдением.
На конференциях обычно хожу на технические доклады, а "смыслы" обхожу стороной. Но на AnalystDays я пошла на доклад к Тане Половинкиной, потому что знаю ее как очень сильного технаря, и ее взгляд на "смыслы" мне было особенно интересно услышать...
Вот какой самый главный инсайт я вынесла из ее выступления:
Иногда важно… поскучать.
С моей многоуровневой многозадачностью это утверждение мне очень откликнулось.
Я думаю, все собравшиеся здесь айтишники живут в режиме постоянной загрузки: рабочие задачи, уведомления, встречи по работе и личные, подкасты на фоне, развитие и статьи «впрок».
"Быть занятым" стало синонимом "быть продуктивным".
Но у сознания есть предел пропускной способности. Только в отличие от ИТ-систем здесь нет DLQ или алертов. Наша голова не уходит в отказ.
Просто внимание рассеивается, и мышление перестаёт быть глубоким. Оно становится реактивным.
Мы не думаем. Мы отвечаем.
И вот Танин доклад напомнил мне, что состояние лёгкой скуки - это не слабость и не прокрастинация.
Это момент восхитительной тишины. Это пауза, в которой:
🔸 оседает пыль информационного шума
🔸 появляются связи между идеями
🔸 формируются собственные выводы
🔸 возвращается стратегическое мышление
Именно в моменты «ничего не происходит» мозг начинает перерабатывать накопленное. Парадоксально, но без периодов пустоты не появляется глубина.
Постоянная занятость создаёт иллюзию движения.
Скука создаёт пространство для смысла.
Это не потерянное время.
Это внутренний кэш, который очищается перед следующей нагрузкой.
Иногда лучший способ двигаться вперёд — на время остановиться...
Не забывайте об этом 🧡
Поставьте реакцию, если вам откликнулось
На конференциях обычно хожу на технические доклады, а "смыслы" обхожу стороной. Но на AnalystDays я пошла на доклад к Тане Половинкиной, потому что знаю ее как очень сильного технаря, и ее взгляд на "смыслы" мне было особенно интересно услышать...
Вот какой самый главный инсайт я вынесла из ее выступления:
Иногда важно… поскучать.
С моей многоуровневой многозадачностью это утверждение мне очень откликнулось.
Я думаю, все собравшиеся здесь айтишники живут в режиме постоянной загрузки: рабочие задачи, уведомления, встречи по работе и личные, подкасты на фоне, развитие и статьи «впрок».
"Быть занятым" стало синонимом "быть продуктивным".
Но у сознания есть предел пропускной способности. Только в отличие от ИТ-систем здесь нет DLQ или алертов. Наша голова не уходит в отказ.
Просто внимание рассеивается, и мышление перестаёт быть глубоким. Оно становится реактивным.
Мы не думаем. Мы отвечаем.
И вот Танин доклад напомнил мне, что состояние лёгкой скуки - это не слабость и не прокрастинация.
Это момент восхитительной тишины. Это пауза, в которой:
🔸 оседает пыль информационного шума
🔸 появляются связи между идеями
🔸 формируются собственные выводы
🔸 возвращается стратегическое мышление
Именно в моменты «ничего не происходит» мозг начинает перерабатывать накопленное. Парадоксально, но без периодов пустоты не появляется глубина.
Постоянная занятость создаёт иллюзию движения.
Скука создаёт пространство для смысла.
Это не потерянное время.
Это внутренний кэш, который очищается перед следующей нагрузкой.
Иногда лучший способ двигаться вперёд — на время остановиться...
Не забывайте об этом 🧡
Поставьте реакцию, если вам откликнулось
❤6👍1