⚡️ Async-коммуникация ломает интеграционные тесты.

Вы отправляете событие в одном модуле… и что дальше? Ждать?

Если используете Thread.Sleep — готовьтесь к:
- медленным тестам
- flaky-поведению
- падениям в CI/CD

Решение — не ждать. Опрос (Polling).

Я использую паттерн Retry Assertion для тестирования асинхронного взаимодействия между модулями:

Как это работает:

1. Выполняем команду (Модуль A)
2. Периодически выполняем запрос (Модуль B)
3. Ждём, пока результат появится
4. Делаем assert

Пример:

var userId = await Sender.Send(new RegisterUserCommand(...));

var result = await Poller.WaitAsync(
    TimeSpan.FromSeconds(15),
    async () =>
    {
        return await Sender.Send(new GetCustomerQuery(userId));
    });

result.Should().NotBeNull();
result.IsSuccess.Should().BeTrue();

Читать полностью…

✔️ Unity обещает создание игр через текстовые команды.

CEO Unity Мэтт Бромберг определил "AI-driven authoring" как приоритетное направление развития компании на 2026 год. Компания готовит инструмент, который сможет собирать казуальные игры с нуля, используя только естественный язык.

Бета-версию Unity AI покажут на GDC в марте 2026 года. Технология будет работать нативно внутри платформы, Unity возьмет топовые внешние модели и доучит их понимать контекст движка.

В компании уверены, что такой подход даст результат лучше, чем попытки заставить универсальные LLM писать сложный игровой код. Цель - окончательная демократизация геймдева, порог входа в который, похоже, скоро исчезнет совсем.
wccftech.com

Читать полностью…

🔥На Stepik вышел курс: Linux: полный апгрейд твоих скиллов

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

Без глубокого знания базы ты не инженер - ты просто пользователь.

🔹 В курсе ты:

- Освоишь bash, grep, sed, awk - инструменты, которыми живут админы.
- Разберёшь права, процессы, сеть, файловую систему и научишься чинить всё, что падает.
- Настроишь SSH, firewall, systemd, crontab, демоны и автозапуск.
- Научишься анализировать логи, следить за нагрузкой, и не паниковать при 100% CPU.

💡 Формат: пошаговое объяснение базы и разбор важных практик по работе с Linux.

🎯 После курса ты: будешь чувствовать Linux как родную среду и забудешь, что такое “permission denied”.

🚀 24 часа действует скидка 30%

👉 Учиться со скидкой

Читать полностью…

⚡️ КАК СДЕЛАТЬ ИНТЕГРАЦИИ БЕЗ ПОТЕРИ ДАННЫХ

Вы регистрируете пользователя и сразу вызываете внешние сервисы:

- сохраняете пользователя в БД
- отправляете welcome-email
- публикуете событие в event bus

public async Task RegisterUserAsync(User user, CancellationToken token)
{
    _userRepository.Insert(user);

    await _unitOfWork.SaveChangesAsync(token);

    await _emailService.SendWelcomeEmailAsync(user, token);
    await _eventBus.PublishAsync(new UserRegisteredEvent(user.Id), token);
}

Вопрос
Что здесь может пойти не так?

Проблемы

— Пользователь сохранён, но email не отправился
— Email отправился, но событие не опубликовалось
— Событие ушло, а транзакция в БД откатилась
— При ретраях возможны дубли

Чем больше внешних вызовов, тем больше точек отказа и сложнее обработка ошибок.

Решение — Outbox Pattern

Сохраняем пользователя и событие в одной атомарной транзакции:

public async Task RegisterUserAsync(User user, CancellationToken token)
{
    _userRepository.Insert(user);

    _outbox.Insert(new UserRegisteredEvent(user.Id));

    await _unitOfWork.SaveChangesAsync(token);
}

Дальше отдельный процесс:

• читает сообщения из Outbox
• отправляет email
• публикует события
• помечает как обработанные

Результат

— Нет рассинхронизации между БД и внешними сервисами
— Гарантированная доставка событий
— Возможность безопасных повторов
— Простая и надёжная архитектура для распределённых систем

Читать полностью…

⚡ Лучший конфиг HttpClient тот, который ты не повторяешь в каждом сервисе.

В .NET всё настраивается один раз через IHttpClientFactory (и Aspire, если используешь его):

• Service discovery для service-to-service вызовов
• Встроенная устойчивость к сбоям (retry, handling transient errors)

После этого ты просто инжектишь клиент и пишешь бизнес-логику — без ручной магии с сокетами, таймаутами и DNS.

Чистый код. Меньше багов. Больше фокуса на логике.

Полный разбор

Читать полностью…

Если вы думаете, что EF Core «медленный» в 2026 — вы просто живёте в прошлом.

Одна из мощных современных фич — bulk-операции, в том числе массовое удаление.

Теперь можно удалить любое количество записей одним запросом к базе.

Пример: e-commerce платформа хочет удалить все корзины, созданные более года назад. Раньше это выглядело так: загрузили сущности в память, RemoveRange, SaveChanges — лишние аллокации, трафик и нагрузка.

Теперь достаточно:

context.Carts
    .Where(o => o.CreatedOn < DateTime.Now.AddYears(-1))
    .ExecuteDelete();

В результате выполняется один SQL DELETE, который напрямую удаляет старые записи в базе — быстро и без промежуточных объектов в памяти.

⚠️ Важно: bulk-операции обходят change tracker EF. Если в контексте уже есть отслеживаемые сущности, состояние может рассинхронизироваться — учитывайте это в логике.

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

Подробнее

Читать полностью…

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

На открытом уроке разберём практическое применение System.Security.Cryptography: AES, RSA, хеширование и цифровые подписи. Поговорим о безопасном хранении и передаче секретов, управлении ключами и принципе наименьших привилегий.

❗️ Вы системно разберёте уязвимости OWASP Top-10 для .NET: инъекции, небезопасную десериализацию, XSS, CSRF — и способы их нейтрализации на уровне кода и архитектуры. Отдельно обсудим шифрование данных в БД, защиту строк подключения и безопасное логирование без утечек токенов.

🟥Встречаемся 10 февраля в 20:00 МСК в преддверии старта курса «C# Developer. Professional».

Зарегистрируйтесь, чтобы не пропустить: https://tglink.io/73e7493a7d6ff1?erid=2W5zFGXFxba
#реклама
О рекламодателе

Читать полностью…

⚡️ Модульный монолит хорош ровно настолько, насколько хороши его границы.

Если Module A может “по-тихому” лезть в базу Module B - у тебя не модули.
У тебя хаос, просто внутри одного репозитория.

Самое сложное в модульной архитектуре - не “разбить на папки”, а решить, что модуль вообще имеет право показывать наружу.

Моё правило для Public API:

1) Начинай с нуля
Считай, что любой класс должен быть приватным по умолчанию.

2) Открывай только по необходимости
Доступ даётся не “на будущее”, а только если другой модуль реально просит функциональность.

3) Экспортируй возможности, а не данные
API должно отражать сценарии (use-cases), а не “вот тебе таблица/репозиторий/DTO”.

И главное - просто договориться недостаточно.
Границы нужно технически запрещать нарушать: модификаторы, сборки, internal, анализаторы, тесты на зависимости.

Читать полностью…

🏗️ Пытаться вытаскивать микросервисы из “спагетти-монолита” - почти всегда плохая идея.

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

Самый безопасный путь миграции - паттерн Strangler Fig:
выносить функциональность по кускам, постепенно “замещая” монолит.

Но есть важное условие:
сначала нужно привести систему к Modular Monolith.

То есть:
- чётко выделить границы модулей
- изолировать данные
- оставить только чистые публичные API для общения между модулями

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

Как выбрать правильного кандидата на первый микросервис?
Ищи 4 “зелёных флага”:

1) Low Coupling - минимум зависимостей от других модулей
2) High Cohesion - логика внутри модуля максимально связная и цельная
3) Distinct Domain - чёткая бизнес-область (например, “платежи” или “инвойсинг”)
4) Scale Needs - модулю нужны другие ресурсы/масштабирование, чем остальной системе

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

Читать полностью…

⚙️ Вы настраиваете ASP.NET Core «по наитию» и тратите время на поиск, почему приложение ведет себя по-разному в продакшене и локально?

📆 29 января в 20:00 OTUS проводит открытый урок «Конфигурирование приложения ASP.NET Core» в преддверии старта курса «C# ASP.NET Core разработчик».

На занятии разберем, как выстроить прозрачную и управляемую систему настроек: appsettings.json, провайдеры конфигурации, приоритет применения конфигураций, настройки специфичные для среды и шаблон Options для работы с настройками. Вы поймете, как проектировать конфигурации так, чтобы приложения были стабильными и предсказуемыми.

❗️Урок будет полезен разработчикам ASP.NET Core начального и среднего уровня, которые хотят систематизировать знания и работать по индустриальным стандартам.

➡️ Регистрируйтесь на бесплатный урок: https://tglink.io/f0de1b0a6e87?erid=2W5zFH3PFGL

🎁 Все участники открытого урока получат скидку на обучение.
#реклама
О рекламодателе

Читать полностью…

📦 Всё ещё не используешь Central Package Management в .NET?

Открой свой .csproj прямо сейчас.

Пакеты обычно выглядят так:
<PackageReference Include="Serilog" Version="4.3.0" />
<PackageReference Include="WolverineFx" Version="5.6.0" />

И в итоге проект превращается в мусорку из версий.

А теперь представь, что это будет так:
<PackageReference Include="Serilog" />
<PackageReference Include="WolverineFx" />

Вот в этом и кайф Central Package Management.

Что он даёт:
✅ .csproj становится чистым и читаемым
✅ никто случайно не поставит “левую” версию пакета
✅ вся команда работает на одинаковых версиях библиотек
✅ сборка становится предсказуемой и детерминированной

Как работает:
Ты управляешь версиями централизованно через файл
Directory.Packages.props в корне репозитория.

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

Если у тебя монорепа или несколько проектов - это must-have.

Читать полностью…

#ПятничныйКвиз #ДляСамыхМаленьких

Читать полностью…

🚀 Опасен баг, который вылазит через 3 дня после релиза.

И это ровно тот риск, который прячется в стандартном Options Pattern в .NET.

Ты спокойно делаешь так:
- биндишь appsettings.json в класс
- инжектишь настройки через DI
- приложение стартует без проблем ✅

А потом внезапно…

В прод падает , потому что:
❌ не задан обязательный ApiKey
❌ RetryCount = 0
❌ строка подключения пустая

И ты узнаёшь об этом только тогда, когда кто-то нажмёт нужную кнопку в твоем приложении.

Вот почему принцип Fail Fast критичен для конфигов:
если конфигурация невалидна - приложение не должно запускаться вообще.

Как это сделать правильно:
используй расширение Options Pattern через IValidateOptions.

Суть подхода:
1) задаём правила (например: ApiKey не null, `RetryCount > 0`)
2) регистрируем валидатор
3) если условия нарушены - DI кидает исключение сразу при старте ✅

Можно прйти дальше и подключиит FluentValidation, чтобы условия были:
- чище
- читабельнее
- удобнее расширять

Полная реализация: https://milanjovanovic.tech/blog/options-pattern-validation-in-aspnetcore-with-fluentvalidation?utm_source=X&amp;utm_medium=social&amp;utm_campaign=05.01.2026

Читать полностью…

🎯 Открытый урок «Сетевой чат на C#».

🗓 22 января в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «C# Developer».

На вебинаре:
✔️ Рассмотрим написание сетевого приложения на C#.
✔️ Мы реализуем простые клиент и сервер с помощью одного из сетевых протоколов.
✔️Также затронем темы многопточности и асинхронности

Кому будет полезно:
• Вебинар будет полезен начинающим разработчикам, желающим разобраться в сетевом и многопочном\асинхронном программировании.

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

🔗 Ссылка на регистрацию: https://otus.pw/zifo/?erid=2W5zFJaPXHA

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

Читать полностью…

Обещанного 3 года ...

Читать полностью…

⚡️ КАСТОМИЗАЦИЯ ИСТОРИИ МИГРАЦИЙ В ENTITY FRAMEWORK

В Entity Framework можно гибко настроить таблицу истории миграций и это полезно в реальных проектах.

По умолчанию EF создаёт таблицу __EFMigrationsHistory в стандартной схеме (dbo).
Но часто требуется:

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

Это можно сделать прямо при настройке DbContext через метод MigrationsHistoryTable.

services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(
        connectionString,
        sqlOptions =>
        {
            sqlOptions.MigrationsHistoryTable(
                tableName: "MigrationHistory",
                schema: "infrastructure"
            );
        }));


// Теперь EF будет хранить историю миграций в:
// infrastructure.MigrationHistory

Читать полностью…

⚡️ Guard Clauses в .NET: проверяй ошибки одной строкой

Хочешь упростить код и избавиться от вложенных if? Используй guard clauses — быстрые проверки входных данных в самом начале метода.

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

В новых версиях .NET появилось много встроенных проверок:

.NET 6:
- ArgumentNullException.ThrowIfNull

.NET 7:
- ArgumentException.ThrowIfNullOrEmpty

.NET 8:
- ThrowIfNullOrWhiteSpace
- ThrowIfNullOrEmpty (для коллекций)
- ThrowIfZero
- ThrowIfNegative
- ThrowIfGreaterThan

Когда это особенно полезно:
- в сервисах и API для валидации входных данных
- в доменных моделях — чтобы не допустить невалидного состояния
- в конструкторах и фабриках

Главная мысль:
Guard clauses — это не про «больше проверок»,
а про ранний отказ и чистую архитектуру.

public class Order
{
    public Order(string customerName, decimal amount)
    {
        ArgumentException.ThrowIfNullOrWhiteSpace(customerName);
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(amount);

        CustomerName = customerName;
        Amount = amount;
    }

    public string CustomerName { get; }
    public decimal Amount { get; }
}

Читать полностью…

#ПятничныйКвиз #ДляСамыхМаленьких

Читать полностью…

🚀 Научитесь создавать AI-проекты и зарабатывать на них

🦾🦾 Сегодня ценится не умение «пользоваться ChatGPT», а навык проектировать и запускать полноценные AI-решения под реальные задачи бизнеса

🤖 Университет искусственного интеллекта - один из самых крупных образовательных проектов в сфере AI:
7 лет на рынке, более 11 000 студентов, практические программы и стажировки в реальных компаниях

🔥🔥 Сейчас открыт доступ к презентации программы GPT Engineer - обучения, где показывают путь от базы до разработки AI-приложений и сервисов

Что вы узнаете из презентации:
🔹 Программа курса по занятиям
🔹 Необходимый уровень для поступления
🔹 Тарифы и цены
🔹 Описание формата практики на стажировках
🔹 Обзор процесса трудоустройства
🔹 Разбор программы поддержки студентов

👉 Если планируете развиваться в сфере искусственного интеллекта или хотите перейти в новую востребованную профессию - обязательно посмотрите презентацию

Читать полностью…

👨‍💻 Ручная сборка, деплой по инструкции в Confluence и ночные правки на сервере — частая реальность ASP.NET-проектов. Пока система доставки не автоматизирована, скорость разработки и стабильность всегда под угрозой.

На открытом уроке разберём, как выстроить рабочий pipeline от коммита до деплоя. Покажем типовую цепочку: сборка, тесты, упаковка в Docker-образ, публикация в реестр и автоматическое развертывание.

❗️ Вы увидите CI/CD не как абстрактную DevOps-теорию, а как воспроизводимый процесс, который можно применить в собственном проекте. Это фундамент для перехода к микросервисам и контейнерной инфраструктуре без лишней сложности.

🗓 Встречаемся 11 февраля в 20:00 МСК в преддверии старта курса «C# ASP.NET Core-разработчик».

➡️ Регистрация открыта: https://tglink.io/3e020aa35caaf6?erid=2W5zFGkbWek

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
#реклама
О рекламодателе

Читать полностью…

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

🖥 C#: t.me/csharp_1001_notes

🖥 ИИ: t.me/ai_machinelearning_big_data

🖥 Python: t.me/pythonl

🖥 Linux: t.me/linuxacademiya

🖥 C++ t.me/cpluspluc

🖥 Docker: t.me/DevopsDocker

🖥 Хакинг: t.me/linuxkalii

🖥 Devops: t.me/DevOPSitsec

👣 Golang: t.me/Golang_google

🖥 Аналитика: t.me/data_analysis_ml

🖥 Javascript: t.me/javascriptv

🖥 Java: t.me/javatg

🖥 Базы данных: t.me/sqlhub

👣 Rust: t.me/rust_code

🤖 Технологии: t.me/vistehno

💰 Экономика и инвестиции в ИИ t.me/financeStable

💼 Актуальные вакансии: t.me/addlist/_zyy_jQ_QUsyM2Vi

🖥 Chatgpt бот в тг: t.me/Chatgpturbobot

📚 Бесплатные ит-книги: /channel/addlist/HwywK4fErd8wYzQy

🖥Подборка по Golang: /channel/addlist/MUtJEeJSxeY2YTFi

⚡️ Лучшие ИИ ресурсы: /channel/addlist/2Ls-snqEeytkMDgy

Самое лучшее в этом: ты учишься даже тогда, когда “нет времени, просто потому что читаешь правильную ленту.

Читать полностью…

Если вы не используете OpenTelemetry, вы буквально летите вслепую в продакшене.

И хорошая новость — вам не нужно переписывать код, чтобы получить “рентген-зрение” для своих сервисов.
Достаточно подключить правильные пакеты авто-инструментирования.

Вот базовый стартовый набор для .NET:

- AspNetCore — автоматически трейсит все входящие HTTP-запросы
- HttpClient — показывает тайминги и статусы всех исходящих API-вызовов
- EF Core — логирует реальные SQL-запросы и их длительность
- Npgsql — добавляет глубокий трейсинг для PostgreSQL
- StackExchange.Redis — помогает увидеть cache hits, misses и скачки латентности

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

Это уже не “логи и надежда”.
Это наблюдаемость продакшен-уровня.

Я разобрал, как всё это подключить к Grafana или Jaeger и получить полноценную визуализацию трейсов.

Полный гайд по настройке:
https://milanjovanovic.tech/blog/introduction-to-distributed-tracing-with-opentelemetry-in-dotnet?utm_source=X&amp;utm_medium=social&amp;utm_campaign=19.01.2026

Читать полностью…

⚡️ 10 причин перейти на .NET 10 (чтобы это одобрил руководитель)

.NET 10 и C# 14 вышли 11 ноября 2025. Ниже - 10 причин, почему апгрейд реально стоит запланировать.

1) LTS-релиз
- .NET 10 - Long-Term Support, поддержка до 14 ноября 2028
- поддержка .NET 8 заканчивается 10 ноября 2026 → лучше не тянуть

2) Быстрее ASP.NET Core
- до +15% RPS по сравнению с .NET 8
- до -93% потребления памяти → меньше нагрузка и дешевле инфраструктура

3) Общий прирост производительности .NET
- сотни улучшений “из коробки” просто после апгрейда проекта

4) File-Based Apps (один .cs файл)
- можно сделать один файл *.cs и запускать напрямую
- удобно для CLI, автоматизации и утилит без создания проекта

5) Server-Sent Events (SSE)
- лёгкий способ стримить данные на клиента
- идеален для real-time обновлений без сложности WebSocket

6) Extension Members в C# 14
- более удобный синтаксис расширений
- можно расширять свойства и static members

7) Minimal APIs: Validation + JSON Patch
- встроенная валидация для Minimal APIs
- JSON Patch доступен из коробки

8) EF 10: LeftJoin / RightJoin в LINQ
- наконец-то нормальные LeftJoin/RightJoin
- запросы становятся проще и читаемее

9) EF 10: Named Query Filters
- можно заводить несколько фильтров на одну сущность
- включать/выключать их независимо

10) Улучшения Blazor
- Hot Reload для Blazor WASM и .NET on WASM
- профилирование производительности + диагностические счётчики

Источник/подробности:
antondevtips.com/draft/10-reasons-to-upgrade-to-dotnet-10/

Читать полностью…

Перестань падать из-за одного внешнего API - добавь Fallback в .NET через Resilience Pipeline 🛡️

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

Идея простая:
Ты добавляешь fallback-стратегию в pipeline, и если запрос падает — система вернёт запасной результат.

Что происходит в примере:

— В DI регистрируется Resilience Pipeline
— Добавляется FallbackStrategy
— Если вызов неудачный, возвращается GitHubUser.Empty вместо исключения

Дальше в endpoint ты не вызываешь HttpClient напрямую — ты запускаешь его через pipeline:

pipeline.ExecuteAsync(...)

И если API:
❌ упало
❌ вернуло ошибку
❌ словило таймаут

Пользователь не увидит 500. Он получит контролируемый ответ.

Это особенно важно для:
- внешних API
- микросервисов
- нестабильных сетей
- интеграций с SaaS

Fallback — это не про «скрыть ошибку».
Это про graceful degradation, когда система продолжает жить даже при частичных сбоях.

Надёжность — это архитектура, а не try/catch в каждом методе.
#dotnet #backend #architecture

Читать полностью…

🖥 Как обычные Linux-пользователи смотрят файлы:

$ ls -a

А как смотрю я:

$ echo */ *. *

Этот трюк выводит всё “простым” способом через glob-расширение:

- */   покажет папки
- *    покажет обычные файлы
- .*   покажет скрытые файлы

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

Читать полностью…

🖥 Многопоточность в .NET часто сводят к lock. Но в реальных системах этого недостаточно — особенно под нагрузкой, в легаси-коде и распределённых сценариях.

📕 На открытом уроке разберём, какие инструменты действительно есть в .NET и как выбирать подходящий примитив под конкретную задачу. Рассмотрим Monitor, Mutex, Semaphore, а также другие примитивы из System.Threading: ReaderWriterLockSlim, Barrier, ManualResetEventSlim, SpinLock.

❗️ Вы увидите практические примеры, типовые ошибки и узнаете, где блокировки становятся узким местом. Урок будет полезен разработчикам, работающим с высоконагруженными системами и легаси-кодом, а также тимлидам, которые проектируют архитектуру и отвечают за производительность.

📣 Встречаемся 27 января в 20:00 МСК в преддверии старта курса «C# Developer. Professional». Регистрация открыта: https://otus.pw/t6Xj/

Читать полностью…

⚡️ Автоматическая регистрация Minimal APIs в .NET - без ручного маппинга

Если в проекте 20+ endpoint’ов, app.MapGet/MapPost превращается в ад.
Решение - авторегистрировать endpoints через DI.

Идея:
1) Делаешь общий интерфейс IEndpoint
2) Каждый endpoint реализует его
3) На старте приложения сканируешь сборку, регистрируешь все реализации в DI
4) Достаёшь их из DI и вызываешь MapEndpoints()

Плюсы:
✅ чистый Program.cs
✅ каждый endpoint в отдельном файле
✅ масштабируется без хаоса
✅ легко тестировать и поддерживать

Пример паттерна:

builder.Services.AddEndpoints(typeof(Program).Assembly);

public interface IEndpoint
{
    void Map(IEndpointRouteBuilder app);
}

public static class EndpointExtensions
{
    public static IServiceCollection AddEndpoints(this IServiceCollection services, Assembly assembly)
    {
        var endpoints = assembly.DefinedTypes
            .Where(t => !t.IsAbstract && !t.IsInterface && typeof(IEndpoint).IsAssignableFrom(t))
            .Select(t => ServiceDescriptor.Transient(typeof(IEndpoint), t))
            .ToArray();

        services.TryAddEnumerable(endpoints);
        return services;
    }

    public static void MapEndpoints(this WebApplication app)
    {
        foreach (var endpoint in app.Services.GetServices<IEndpoint>())
            endpoint.Map(app);
    }
}

Читать полностью…

⚡️ В .NET кэш - это всегда выбор: максимальная скорость или единые данные между серверами.

IMemoryCache
✅ Очень быстрый
❌ Работает только внутри одной ноды
(в кластере из 10 серверов у вас 10 разных кэшей)

Redis / IDistributedCache
✅ Один общий кэш на все ноды - данные одинаковые
❌ Медленнее: сеть + сериализация + лишние накладные расходы

Правильный подход - Hybrid Cache.

Он не заставляет выбирать - он комбинирует оба мира:

- L1 (Local / RAM) - сначала читаем из памяти приложения (самый быстрый слой)
- L2 (Distributed / Redis) - если локально нет, идём в общий кэш
- Source (DB/API) - если нет и там, берём из источника и прогреваем оба уровня

🚀 скорость как у MemoryCache
🔒 данные согласованы между нодами как в Redis
📉 меньше нагрузки на БД и меньше «холодных» запросов

Microsoft делает нативный HybridCache, но если нужно решение уже сейчас - FusionCache остаётся самым надёжным и реально продакшн-готовым вариантом.

📌 Гайд

Читать полностью…

Не все стратегии балансировки нагрузки одинаково полезны.

Если ты используешь YARP (Yet Another Reverse Proxy) в .NET - у него есть 5 встроенных способов распределять трафик между серверами. Но какой выбрать?

Вот понятный разбор:

1) RoundRobin (по кругу)
Классика: запросы равномерно идут по очереди на каждый сервер.
✅ просто
❌ плохо работает, если сервера/запросы не одинаковые по скорости

2) LeastRequests (минимум активных запросов)
Самый “умный” вариант: отправляет запрос туда, где сейчас меньше всего работы.
✅ отлично при разном времени обработки запросов
✅ помогает снизить задержки на “хвосте” (tail latency)

3) Random (случайно)
Сервер выбирается случайно.
✅ неожиданно хорошо работает при большом потоке однотипных запросов
❌ может иногда “не повезти” и нагрузить один сервер сильнее

4) PowerOfTwoChoices (2 случайных - выбираем лучший)
Баланс между качеством и стоимостью: берём 2 случайных сервера и выбираем тот, где меньше активных запросов.
✅ почти как LeastRequests, но дешевле по логике
✅ не надо проверять все сервера каждый раз

5) FirstAlphabetical (первый доступный)
Всегда выбирает “первый” сервер из списка (условно самый верхний/раньше по имени).
✅ хорошо для failover (есть основной сервер, остальные - запасные)
❌ плохо распределяет нагрузку (по сути почти без балансировки)

Большинство по привычке ставят RoundRobin, но если время обработки запросов разное - переход на LeastRequests часто заметно улучшает tail latency.

Разбор с примерами, как масштабировать ASP.NET Core API через YARP

А какая стратегия у тебя по умолчанию?

Читать полностью…

.NET 9 стал гораздо устойчивее к сбоям 💪

В .NET 9 появились официальные пакеты для отказоустойчивости:

- Microsoft.Extensions.Resilience
- Microsoft.Extensions.Http.Resilience

Они построены поверх Polly, поэтому API знакомый - легко описывать политики:

- retry
- circuit-breaker
- fallback
- timeout
- hedging
- rate limiter

Подключаете и ваши HTTP-клиенты и сервисы автоматически восстанавливаются при сетевых ошибках и таймаутах.

Итог: меньше падений и больше стабильности. Отлично для продакшена 🚀

Читать полностью…