Как выбрать первый модуль для выделения в отдельный сервис

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

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

Часть локальных вызовов станет сетевой. Понадобятся тайм-ауты, обработка сбоев и распределённая трассировка, чтобы отслеживать запрос между приложениями.

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

Руководство по выделению первого сервиса и переносу данных

👉 @KodBlog

👉 @KodBlog

12 библиотек .NET, о которых стоит знать каждому разработчику

Сохраняйте подборку и делитесь с коллегами 🔖

👉 @KodBlog

Заказ сохранился, но так и не отправился

Приложение записывает заказ в БД, затем публикует событие для запуска доставки. Если брокер недоступен, а приложение остановится до повторной попытки, событие может потеряться.

Transactional Outbox помогает пережить такой сбой. Заказ и событие сохраняются в одной транзакции БД: либо фиксируются обе записи, либо ни одна.

Фоновый обработчик читает таблицу outbox и отправляет события брокеру. Если отправка не удалась, запись остаётся для повторной попытки.

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

Поэтому получатель должен обрабатывать дубликаты безопасно. Повторное сообщение не должно приводить к повторной отправке заказа.

Проверьте оба сценария:

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

Разбор механизма и настройки в EF Core

👉 @KodBlog

Автоматическая регистрация зависимостей со Scrutor в ASP.NET Core

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

Меньше ручных регистраций — особенно когда в проекте много однотипных сервисов.

👉 @KodBlog

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

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

👉 @KodBlog

Параллельное ожидание async-операций в .NET

Не ожидайте независимые асинхронные операции по очереди. Запустите их сразу, а затем дождитесь завершения через Task.WhenAll() — общее время не будет складываться из времени каждой операции.

👉 @KodBlog

lock в C# не остановит второй экземпляр приложения

Когда приложение работает в нескольких экземплярах, каждый может запустить одну и ту же задачу по расписанию. У каждого процесса свой lock в памяти.

Для координации можно использовать advisory lock в PostgreSQL: оба экземпляра пытаются получить одну и ту же блокировку. Получивший запускает задачу, другой пропускает попытку.

Но есть нюансы:

• Сессионная блокировка удерживается соединением с БД. Если соединение потеряно, другой воркер может получить её, пока первый ещё выполняет работу.
• Блокировка не хранит историю выполненных запусков — их нужно учитывать отдельно.
• Повторное выполнение должно быть безопасным: блокировка сама по себе не гарантирует «ровно один раз».

Разбор и пример на C#

👉 @KodBlog

12 возможностей современного C#, которые стоит знать .NET-разработчику

C# заметно изменился: лаконичный синтаксис, средства работы с null, улучшения производительности и инструменты для конкурентного выполнения задач помогают писать более понятный и надёжный код.

Собрали 12 возможностей, которые пригодятся в повседневной разработке.

👉 @KodBlog

Отдельная схема БД ещё не изолирует данные модуля

Если все модули используют одну учётную запись PostgreSQL, она может иметь доступ ко всем таблицам. Названия папок и схем этих прав не меняют.

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

При этом каждому модулю по-прежнему нужны свой DbContext и явный контракт доступа к общим данным. Для совместного чтения владеющий модуль может предоставить API или представление (VIEW) с намеренно выданными правами.

Так границы модулей становятся проверяемым ограничением, а не просто договорённостью команды.

Практическое руководство: роли PostgreSQL, права доступа и настройка EF Core

👉 @KodBlog

Singleton, Scoped и Transient в ASP.NET Core

Время жизни сервиса влияет на потребление памяти, состояние приложения и безопасность работы с несколькими потоками.

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

Scoped — один экземпляр на scope, обычно на HTTP-запрос. Подходит для EF Core DbContext и состояния запроса. В фоновых сервисах scope нужно создавать явно.

Transient — новый экземпляр при каждом получении из DI. Подходит для лёгких независимых сервисов. Частое создание добавляет расходы на выделение памяти и инициализацию. Если такой объект сохраняется в Singleton, он остаётся жить вместе с ним.

Частая ошибка — внедрить Scoped-сервис в Singleton. Это может привести к некорректному разделению состояния и конфликтам при одновременных обращениях. Проверка scope помогает обнаружить такую зависимость.

Для выполнения операции создавайте отдельный scope через IServiceScopeFactory:

await using var scope = scopeFactory.CreateAsyncScope();

var service = scope.ServiceProvider
    .GetRequiredService<IMyScopedService>();

await service.ProcessAsync();

Для работы с БД внутри BackgroundService можно использовать такой scope или IDbContextFactory<TContext>:

await using var db =
    await dbContextFactory.CreateDbContextAsync();

var orders = await db.Orders.ToListAsync();


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

👉 @KodBlog

Два запроса — одна квартира — двойное бронирование

Оба запроса могут проверить доступность квартиры и увидеть свободные даты. Проблема возникает между проверкой и сохранением: за это время другой запрос успевает создать бронь.

Один из способов защиты — оптимистическая конкуренция через общую строку квартиры. При создании бронирования каждый запрос также обновляет эту строку в одной транзакции. У неё есть токен версии, который меняется при обновлении.

EF Core добавляет прочитанную версию в условие UPDATE. Первый запрос успешно сохраняет изменения. Второй использует уже устаревшую версию и получает DbUpdateConcurrencyException; его транзакция откатывается.

После конфликта нельзя просто повторить запись. Нужно заново прочитать актуальные данные и проверить доступность дат.

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

Разбор и пример на EF Core

👉 @KodBlog

Сны вайб-кодеров 🐺

👉 @KodBlog

«Запрос использует индекс» — это ещё не значит, что с производительностью всё в порядке.

Допустим, нужно получить последний комментарий к задаче. Индекс отсортирован сначала по ID задачи, затем по ID пользователя и только потом по дате. Он позволяет найти комментарии к нужной задаче, но внутри они сгруппированы по пользователям, а уже затем отсортированы по дате. Это не тот порядок, который нужен запросу, поэтому базе данных всё равно может потребоваться дополнительная сортировка.

В запросе для дашборда такая работа может повторяться для каждой задачи.

План выполнения запроса помогает проверить условия фильтрации, порядок сортировки и количество циклов выполнения. Для такого запроса лучше подойдёт индекс по ID задачи и дате.

Но даже в этом случае нужно измерять производительность всего запроса. Дополнительные индексы занимают место и увеличивают нагрузку при записи данных.

В примере с PostgreSQL показано, как порядок столбцов в индексе влияет на план выполнения.

👉 @KodBlog

Rate Limiting в ASP.NET Core: одного middleware недостаточно

Ограничение частоты запросов помогает защитить API от перебора паролей, злоупотребления запросами, резких скачков трафика и чрезмерного потребления ресурсов.

Но полагаться только на middleware внутри приложения — ошибка. Защищать нужно всю цепочку обработки запросов:

CDN и защита от DDoS → WAF → API Gateway → .NET API → внутренние сервисы

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

Надёжная защита API — это не одна настройка, а многоуровневый подход.

👉 @KodBlog

Таймаут в ASP.NET Core не гарантирует остановку выполнения

Middleware для ограничения времени выполнения в ASP.NET Core отменяет токен отмены (CancellationToken), но не останавливает поток принудительно и не заставляет endpoint немедленно вернуть ответ.

Чтобы таймаут действительно помогал, токен должен передаваться по всей цепочке вызовов: от endpoint через сервисы до EF Core или HttpClient. При этом вызываемый код тоже должен поддерживать отмену.

В примере из статьи для endpoint установлен лимит в 3 секунды. Но если внутри него выполняется десятисекундная задержка, которая игнорирует токен отмены, обработка может продолжиться и завершиться ответом 200 OK.

Проверить поведение можно в двух сценариях: когда операция корректно реагирует на отмену и когда игнорирует её. Тестировать нужно без подключённого отладчика — в описанном примере таймаут не срабатывает под отладчиком.

Разбор настройки таймаутов и обработки отмены в ASP.NET Core

👉 @KodBlog

7 архитектур .NET, которые должен знать каждый разработчик в 2026 году

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

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

Монолитная архитектура (Monolithic Architecture). Подходит для небольших приложений, MVP и проектов с простой предметной областью. Такие приложения быстро разрабатывать, но их масштабирование со временем может стать сложнее.

Многоуровневая архитектура (N-Tier Architecture). Классический подход с чётким разделением ответственности между уровнями. Идеально подходит для корпоративных приложений, хотя компоненты всё ещё могут оставаться тесно связанными.

Чистая архитектура (Clean Architecture). Предполагает независимость бизнес-логики от фреймворков и пользовательского интерфейса. Отлично подходит для систем, которые должны оставаться удобными в поддержке и тестировании в долгосрочной перспективе.

Архитектура вертикальных срезов (Vertical Slice Architecture). Организует код по функциональным возможностям, а не по слоям. Хорошо подходит для гибких команд и позволяет быстрее разрабатывать новые функции.

Микросервисная архитектура (Microservices Architecture). Подходит для крупных систем, которым необходимы независимое развёртывание компонентов и высокая масштабируемость. Однако такой подход усложняет эксплуатацию и поддержку инфраструктуры.

CQRS (Command Query Responsibility Segregation). Разделяет операции чтения и записи данных. Особенно полезен для высоконагруженных систем и приложений со сложной бизнес-логикой.

Событийно-ориентированная архитектура (Event-Driven Architecture). Обеспечивает слабую связанность компонентов и обработку событий в реальном времени. Подходит для распределённых систем и интеграции различных сервисов.

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

👉 @KodBlog

Обрати внимание, где именно расположен ToList() в этом посте про Entity Framework, который я сегодня увидел в LinkedIn.

СПОЙЛЕР: Оба варианта генерируют практически одинаковый SQL-запрос (за исключением того, что в правом варианте столбец City не выбирается).

Однако мне больше нравится правый вариант, где Where стоит перед Select, — с точки зрения стиля и читаемости кода.

👉 @KodBlog

Clean Architecture нужна не каждому .NET-проекту

При разработке на ASP.NET Core легко увлечься архитектурой и создать несколько слоёв абстракций даже для простых функций. Но иногда Vertical Slice Architecture (VSA) позволяет писать код проще и быстрее.

Вместо разделения приложения на слои VSA группирует код по функциям и сценариям: например, CreateOrder, GetOrder и CancelOrder. Внутри каждого слайса находятся необходимые обработчики, валидация, модели запросов и ответов.

В чём преимущества VSA?

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

Это не значит, что Clean Architecture устарела. Она по-прежнему отлично подходит проектам со сложной бизнес-логикой и строгими архитектурными границами.

Практичный подход — начать с Vertical Slice Architecture и добавлять слои и абстракции по мере необходимости. При этом важно следить, чтобы логика не дублировалась между слайсами.

👉 @KodBlog

Кто я такой, чтобы спорить 🦀

👉 @KodBlog

HTTPS-редиректа недостаточно для защиты приложения ASP.NET Core

Многие разработчики включают UseHttpsRedirection() и считают, что приложение защищено. Но есть ещё один важный механизм безопасности, о котором не стоит забывать, — HTTP Strict Transport Security (HSTS).

Разберёмся, как они работают вместе.

1. HTTPS-редирект: UseHttpsRedirection()
Автоматически перенаправляет входящие HTTP-запросы на HTTPS. Например: http://example.com → https://example.com

Однако первый HTTP-запрос всё ещё может передаваться по незащищённому соединению до выполнения перенаправления.

2. HSTS: UseHsts(). HSTS указывает браузеру использовать для домена только HTTPS. Получив заголовок HSTS по защищённому соединению, браузер:

• Автоматически переключает последующие HTTP-запросы на HTTPS.
• Не позволяет пользователю обойти предупреждение о недействительном сертификате.
• Помогает защититься от атак, связанных с понижением версии протокола.

3. Настройка обоих механизмов в ASP.NET Core

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHsts(options =>
{
    options.MaxAge = TimeSpan.FromDays(365);
    options.IncludeSubDomains = true;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseHsts();
}

app.UseHttpsRedirection();

app.MapGet("/", () => "Secure API");

app.Run();

Здесь HSTS действует в течение одного года, а директива IncludeSubDomains распространяет его действие на поддомены.

Важно: включайте IncludeSubDomains, только если все поддомены поддерживают HTTPS.

4. Что учитывать в production

• Обратные прокси. Если используются AWS ALB, Nginx или другой reverse proxy, завершение HTTPS-соединения и перенаправление могут выполняться на уровне инфраструктуры.

• Forwarded-заголовки. При необходимости настройте UseForwardedHeaders() для доверенных прокси до UseHttpsRedirection(). Иначе приложение может неправильно определять схему запроса и создавать циклы перенаправлений.

• Web API. HSTS применяется преимущественно браузерами. Для API, которыми пользуются мобильные приложения и другие клиенты, необходимо обеспечивать HTTPS на уровне сервера или инфраструктуры, а не полагаться на редиректы.

• HSTS Preload. Рассматривайте предварительное включение домена в список HSTS только тогда, когда весь домен и все его поддомены постоянно готовы работать через HTTPS.

Рекомендация: обеспечивайте принудительное использование HTTPS на границе инфраструктуры, а для приложений, доступных через браузер, дополнительно используйте HSTS. Важно, чтобы оба механизма были настроены согласованно.

👉 @KodBlog