Крутая статья - «Building an Event Queue in ASP.NET Core» от Deepumi.

🔹 Она показывает, как правильно построить очередь событий внутри ASP.NET Core-приложения:
• использовать встроенные механизмы (middleware / DI)
• распределять события между обработчиками
• обрабатывать события асинхронно и надёжно

🔹 Такая архитектура помогает:
• реализовать decoupled компоненты, которые не знают друг о друге
• централизовать событие-поток (логика, оповещения, триггеры и т.п.)
• легче масштабировать и тестировать код

Если работаешь с ASP.NET Core и хочешь сделать систему событий - стоит заглянуть.

Подробнее: deepumi.com/blog/building-an-event-queue-in-aspnet-core.html

🚦 Feature Flags в .NET - как управлять релизами без redeploy

Feature flags (фиче-флаги) позволяют включать и выключать функциональность на лету, без повторного деплоя и риска для продакшена.

Идея простая:
код задеплоен → поведение управляется конфигурацией.

Что это даёт на практике:
— Постепенные релизы
Можно включить новую фичу сначала для 1%, 10% или конкретной группы пользователей.
— Быстрый rollback
Если что-то пошло не так — просто выключаете флаг. Без откатов и срочных хотфиксов.
— A/B тесты
Разные пользователи получают разное поведение одного и того же кода.
— Targeting пользователей

Фичи можно включать:
• по user id
• по роли
• по региону
• по environment (dev / staging / prod)

— Меньше фиче-веток
Код живёт в main, а не за флагами в git.

В .NET обычно используют:
- Microsoft.FeatureManagement
- Azure App Configuration
- LaunchDarkly / Unleash / ConfigCat

Где это особенно полезно:
- публичные API
- high-traffic сервисы
- SaaS-продукты
- экспериментальные и рискованные фичи

Коротко:
Feature flags превращают релиз из «одного опасного момента» в управляемый процесс.

Это один из самых мощных инструментов для зрелой backend-архитектуры.

👉 Подробнее

🧠 Polyglot Persistence: как современные системы живут с десятками баз данных

🔥 23 декабря в 20:00 мск — открытый вебинар в OTUS.

Одна база данных больше не справляется с требованиями современного мира. Сегодня компании вроде Avito, Yandex, Ozon и Spotify объединяют PostgreSQL, ClickHouse, Redis, Kafka, Elasticsearch и десятки других инструментов в единую экосистему, где каждая БД отвечает за свой кусочек производительности.

📌 На вебинаре разберём:
— Принципы Polyglot Persistence и как распределять роли между СУБД
— Как связать PostgreSQL, ClickHouse, Redis и Kafka без потери согласованности
— Как работают event-driven архитектуры, CDC и outbox-паттерн в боевых системах
— Как проектировать отказоустойчивые data-платформы

Регистрация https://otus.pw/enVW/?erid=2W5zFHSfqbE

Бесплатное занятие приурочено к старту курса Highload Architect, где вы научитесь проектировать системы, выдерживающие миллионы запросов.



Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🛠 Как оживить протухшую ветку без merge-хаоса

Бывает: вы увлеклись разработкой, прошло пару недель (или месяцев), а основная ветка уже ушла далеко вперёд. В итоге — боль, конфликты и бесконечные merge-коммиты.

В таких случаях может спасати ребейз на свежую ветку:

git pull --rebase origin release/1.2.0

Она подтянет последние изменения из релизной ветки и наложит ваши коммиты поверх, сохранив линейную историю.

Конфликты всё равно придётся разруливать, но по одному — в контексте конкретного коммита, а не в гигантской свалке.

После успешного ребейза пушим с --force-with-lease, чтобы аккуратно обновить удалённую ветку, и продолжаем работать так, как будто отставания и не было.