Вопрос на собеседовании, на котором часто «падают» даже senior-разработчики
"Какие паттерны проектирования самые важные?"

Большинство разработчиков изучает паттерны хаотично.
Но не все паттерны одинаково полезны на каждом этапе карьеры.

Вот как к ним подходить разумно 👇

Начните с этих (𝗖𝗼𝗿𝗲 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀)
Это ваша база. Вы будете использовать их почти в каждом коде:

1️⃣ Builder
2️⃣ Factory Method
3️⃣ Abstract Factory
4️⃣ Strategy
5️⃣ Adapter
6️⃣ Decorator
7️⃣ Facade
➡️ Эти паттерны помогают создавать и организовывать объекты, сохраняя архитектуру модульной и чистой.

Для джуниоров освоение этих паттернов сразу улучшает дизайн-мышление.

Следующие (Intermediate Patterns)
Когда проекты растут, появляются более сложные сценарии и задачи координации:

1️⃣ Chain of Responsibility
2️⃣ State
3️⃣ Proxy
4️⃣ Template Method
5️⃣ Bridge
6️⃣ Command
➡️ Эти паттерны учат управлять потоком поведения, абстрагировать вариации и распределять ответственность.

Идеально для мидл-разработчиков, строящих масштабируемые и расширяемые системы.

Когда архитектура становится сложной (𝗔𝗱𝘃𝗮𝗻𝗰𝗲𝗱 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀)
Эти паттерны встречаются в больших системах, фреймворках и архитектурах с глубокой предметной областью:
1️⃣ Singleton
2️⃣ Mediator
3️⃣ Flyweight
4️⃣ Interpreter
5️⃣ Composite
6️⃣ Visitor
7️⃣ Prototype
➡️ Они помогают оптимизировать производительность, координировать подсистемы и управлять иерархией объектов.

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

👉 @KodBlog

Шпаргалка по сложности алгоритмов

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

⛓ Ознакомиться: тут

👉 @KodBlog

Шпаргалка по REST API для начинающих

Шесть фундаментальных принципов, которые служат строительными блоками архитектуры REST API:

- Клиент-серверная архитектура
- Взаимодействие без сохранения состояния
- Возможность кэширования
- Многоуровневая система
- Поддержка кода по требованию
- Унифицированный интерфейс

👉 @KodBlog

Опубликован разбор union types в .NET 11 и C#: https://andrewlock.net/exploring-the-dotnet-11-preview-2-dotnet-gets-union-types/

Автор рассматривает:
- поддержку union types в .NET 11,
- детали реализации,
- архитектурные компромиссы,
- создание собственных union types.

👉 @KodBlog

AI Agent Governance Toolkit — от Microsoft

Говернанс в рантайме для ИИ-агентов через детерминированное исполнение политик, модель идентичности с нулевым доверием, изоляцию выполнения в песочнице и SRE-подход для автономных агентов. Покрывает все 10 рисков OWASP Agentic с более чем 13 000 тестов.

https://github.com/microsoft/agent-governance-toolkit

👉 @KodBlog

Как сделать настройку приложения максимально читаемой и управляемой.

Достаточно одной возможности языка C# — методов расширения.

Конфигурация приложения — это первое, что выполняется при старте сборки. Со временем Program.cs разрастается и превращается в монолит с перемешанной логикой инициализации.

Это можно избежать.

Здесь применяется паттерн расширений для ServiceCollection. Он позволяет разнести конфигурацию сервисов на отдельные модули и собрать их в компактные, изолированные блоки.

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

👉 @KodBlog

Вышел предварительный релиз .NET 11, версия 4

- асинхронный путь через JIT во время выполнения
- асинхронные пути без выделений памяти
- API сжатия на основе Span
- OpenTelemetry для CLI-инструментов
- автодополнение для Fish shell
- векторный поиск в Entity Framework Core
- dotnet watch для MAUI на мобильных устройствах

Читать блог

👉 @KodBlog

В каком-то всеми забытом углу Qt внезапно зарелизили поддержку C#: https://www.qt.io/blog/qt-bridges-public-beta-for-csharp

👉 @KodBlog

Размер веб-страницы должен укладываться в 14кБ

Меньше размер – быстрее загрузка, это понятно. Удивительно, что страница в 14кБ может загружаться гораздо быстрее, чем в 15кБ, а разница между 15 и 16кБ незначительна. Дело в алгоритме медленного старта TCP.

TCP
Протокол управления передачей (TCP) — это способ использования интернет-протокола (IP) для надёжной отправки пакетов данных. Сервер отправляет несколько пакетов, затем ждёт ответа от браузера о получении (ACK), затем отправляет ещё — или, если не получил ACK, может отправить пакеты снова.

Алгоритм медленного старта TCP используется серверами для определения количества пакетов, которые они могут отправить за один раз. Сервер не знает, какой объём данных может обработать соединение, поэтому начинает с отправки небольшого и безопасного количества данных — обычно 10 TCP-пакетов. Если на это получен ACK, сервер отправляет больше данных, удваивая количество пакетов. Так до тех пор, пока пакеты не будут потеряны и сервер не получит ACK. (Тогда он продолжает отправлять пакеты, но с меньшей скоростью). В реальности реализация алгоритма может отличаться, но суть та же.

Откуда 14кБ?
Максимальный размер TCP-пакета составляет 1500 байт: 40 байт заголовка (16 – IP, 24 – TCP). Т.е., 10 пакетов по 1460 = 14600 байт или примерно 14кБ!

Таким образом, если страницы (хотя бы важные) вашего сайта умещаются в 14кБ, вы можете сэкономить посетителям много времени. Люди очень нетерпеливы, и даже один обмен данными может быть удивительно долгим, особенно в нестабильных сетях.

Что делать?
Очевидно – делать сайт как можно меньше. Хорошая цель – уместить каждую страницу в 14кБ. Эти 14кБ включают сжатие — так что на самом деле это может быть около 50кБ несжатых данных, что довольно много.

Так что, если избавиться от лишнего CSS и JS, автовоспроизводимых видео, использовать минимизацию кода и т.п., вы, вероятно, легко достигнете цели. Но, даже если этого не получится, из правила 14кБ всё ещё можно извлечь пользу. Первые 14кБ данных, отправляемых посетителям, могут быть использованы для отображения чего-то полезного — например, важных первых нескольких абзацев текста, объясняющих, как использовать ваше приложение.

Примечание: 14кБ включают в себя HTTP-заголовки — которые не сжимаются (даже в HTTP/2 при первом ответе), а также изображения, поэтому выдавайте только то, что находится в видимой области экрана, делайте их очень маленькими, или используйте заполнители, чтобы посетители знали, что на этом месте будет что-то полезное.

Некоторые оговорки:
- Правило 14кБ больше эмпирическое правило, чем фундаментальный закон вычислительной техники. Некоторые серверы увеличили начальное окно медленного старта TCP до 30 пакетов вместо 10.
- Иногда сервер знает, что может начать с большего количества пакетов, потому что он использовал TLS-рукопожатие для установления большего лимита.
- Серверы могут кэшировать количество пакетов, которые может обработать маршрут, и отправлять больше при следующем подключении.

👉 @KodBlog

ВЫШЕЛ CodeAlta — один из первых эффективных AI-кодинг-агентов с TUI, полностью написанный на C#/.NET

CodeAlta предлагает вам красивый цветной интерфейс-таймлайн, несколько потоков в одном workspace, полноценный опыт редактора промптов, быстрое просмотр/редактирование файлов с подсветкой синтаксиса, встроенную настройку провайдеров моделей, среду, готовую для multi-agent, и многое другое

Website: https://codealta.github.io/
GitHub: https://github.com/CodeAlta/CodeAlta

Установка:
Для установки достаточно установленного .NET 10 и команды:

dotnet tool install -g CodeAlta

👉 @KodBlog

Чувак использовал ExecuteDelete на таблице с soft delete. 2000 промо-товаров были навсегда удалены.

Джоба очистки работала месяцами без проблем. Потом он добавил soft delete — SaveChangesInterceptor, который вместо настоящего DELETE просто выставляет IsDeleted.

ExecuteDelete полностью обходит весь пайплайн.

ExecuteDelete генерирует «сырой» SQL DELETE. Он не вызывает SaveChanges. Interceptor не срабатывает. Change Tracker не видит сущность. Строки удаляются, флаг IsDeleted не устанавливается, и audit trail не записывается.

Фикс — одна строка: использовать ExecuteUpdate, чтобы переключать IsDeleted вместо этого.

Правило: если сущность участвует в soft delete или любом паттерне через SaveChangesInterceptor, никогда не используйте ExecuteDelete для неё. Переходите на ExecuteUpdate с SetProperty(IsDeleted, true), либо загружайте сущности и используйте RemoveRange + SaveChanges, чтобы interceptor отработал.

👉 @KodBlog

6 трендов в .NET, которые убивают ваши проекты

Каждый .NET-туториал преподносит их как «лучшие практики».

После 12+ лет разработки реальных систем Антон отказался от всех шести.

Вот что он использует вместо них.

1. Clean Architecture везде

Проблема:

- 4 проекта и 5 слоёв, через которые приходится проходить, чтобы добавить один эндпоинт.

Что использовать вместо этого:

- Vertical Slice Architecture.
- Весь код одной фичи находится в одной папке.

Принципы Clean Architecture стоит добавлять только тогда, когда сложность проекта действительно этого требует: например, при богатой доменной модели или необходимости чёткого разделения инфраструктурных зависимостей.

Небольшие сфокусированные классы экономят токены при работе с AI. Кроме того, AI-агентам гораздо проще находить код нужной фичи, когда он расположен в одном месте.

2. Микросервисы с первого дня

Проблема:

- Распределённые транзакции.
- Сложная отладка.
- Хаос с развёртыванием.

Что использовать вместо этого:

- Начинать с модульного монолита (Modular Monolith).
- Выделять микросервисы только после появления реальных проблем масштабирования.

Большинство приложений не доходят до миллиона пользователей. Гораздо чаще они прекращают развитие ещё на первых сотнях пользователей.

Лучшие микросервисы обычно вырастают из модульного монолита.

3. Библиотеки для маппинга

Проблема:

- AutoMapper, Mapster и Mapperly скрывают логику маппинга.
- Теряется прямая навигация по коду.
- Приходится тратить время на разбор особенностей библиотек.

Что использовать вместо этого:

- Ручной маппинг.

Преимущества:

- Полный контроль над кодом.
- Прямая навигация.
- Простая отладка.

С появлением AI-агентов код для маппинга создаётся за считаные секунды, поэтому библиотеки маппинга уже не дают заметной экономии времени.

4. MediatR везде

Проблема:

- Нет прямой навигации от эндпоинта к обработчику.
- Появляются дополнительные команды, интерфейсы и шаблонный код только ради соблюдения паттерна.

Что использовать вместо этого:

- Обычные классы обработчиков без интерфейсов.
- Внедрение через DI и прямой вызов из эндпоинтов.

Результат:

- То же разделение ответственности.
- Меньше кода.
- Полноценная навигация в IDE в один клик.

5. EF Core через репозитории

Проблема:

- EF Core уже реализует паттерны Repository и Unit of Work.
- Дополнительные репозитории создают лишний уровень абстракции.

Что использовать вместо этого:

- DbContext напрямую в обработчиках приложения.

Не стоит создавать обёртки поверх уже существующих обёрток.

Иначе скрываются основные возможности EF Core:

- LINQ.
- Change Tracking.
- Проекции.

6. Unit-тесты по умолчанию

Проблема:

- Unit-тесты с большим количеством моков создают ложное чувство уверенности.
- Тесты проходят успешно, а приложение всё равно падает в продакшене.

Что использовать вместо этого:

- Интеграционные тесты как основной вид тестирования.

Используйте WebApplicationFactory и TestContainers для проверки полного сценария работы:

реальный эндпоинт → реальная база данных

Такой подход также проверяет:

- конфигурацию приложения;
- контейнер зависимостей (DI);
- middleware;
- миграции базы данных.

Главное правило: Не добавляйте сложность, если проект в ней не нуждается.

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

👉 @KodBlog

В том году я заменил 20 Python-скриптов на C#

Годами каждый раз, когда нужен был 20-строчный скрипт, я создавал solution, добавлял csproj и ждал завершения генерации шаблона.

Именно поэтому я переключился на Python для таких задач.

.NET 10 изменил ситуацию, а .NET 11 Preview 3 довёл её до логического завершения.

Теперь можно запускать один C#-файл напрямую:

dotnet run hello.cs

Без solution.
Без проекта.
Только код.

4 директивы, которые меняют всё:

Они превращают один файл в полноценное .NET-приложение.

1. #:package

Позволяет подключить любой NuGet-пакет одной строкой.

#:package Newtonsoft.Json@13.0.3

2. #:sdk

Позволяет сменить SDK и получить доступ к ASP.NET Core.

#:sdk Microsoft.NET.Sdk.Web

3. #:project

Позволяет сослаться на существующую библиотеку классов.

#:project ../MyLibrary/MyLibrary.csproj

4. #:include (новинка в .NET 11 Preview 3)

Позволяет разбивать код на несколько файлов.

#:include models.cs

Именно эта директива стала настоящим прорывом.

В .NET 10 file-based приложения были ограничены одним файлом.

Теперь можно организовать структуру настоящего приложения: модели в одном файле, сервисы — в другом, точка входа — в main.cs.

Первые 5 Python-скриптов, которые я\ заменил:

- Преобразование JSON и CSV.
- Smoke-тесты внутренних API после деплоя.
- Парсинг логов для поиска и анализа ошибок.
- Сидирование базы данных для локальной разработки.
- HTTP health-check утилиты для staging-окружений.

Выгода оказалась огромной.

Получаем:

- строгую типизацию;
- IntelliSense;
- async/await из коробки.

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

А когда скрипт перерастает свой первоначальный формат, его можно превратить в полноценный проект одной командой:

dotnet project convert main.cs

👉 @KodBlog

NuGet Package Pruning в .NET 10 = дзен в управлении зависимостями

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

Команды получают:
- на 70% меньше отчётов об уязвимостях;
- более быстрое восстановление пакетов (ускорение до 50%).

Подробнее: https://devblogs.microsoft.com/dotnet/nuget-package-pruning-in-dotnet-10/

👉 @KodBlog

Каждый .NET-проект на микросервисах рано или поздно сталкивается с одними и теми же 5 проблемами.

Большинство команд подключают для их решения 5 разных библиотек.
Но есть способ проще.

На прошлой неделе я заново реализовал систему бронирования отелей с четырьмя микросервисами.
В типичной архитектуре мне понадобились бы:
→ MassTransit для обмена сообщениями
→ Polly для повторных попыток (retries)
→ Refit + HttpClient для вызовов сервисов
→ клиент для Vault для работы с секретами
→ Redis SDK для кеширования и распределённых блокировок

Пять SDK.
Пять способов конфигурации.
Пять разных ментальных моделей.

Вместо этого я использовал Dapr — один runtime, один клиент и единый API для всего.
Вот эти 5 проблем и то, как Dapr их решает.

1. Вызовы между сервисами
Вы обращаетесь к сервисам по App ID, а не по URL.

await daprClient.InvokeMethodAsync(
    "hotels-api",
    "rooms/available");

Dapr берёт на себя:
- service discovery;
- retries;
- трассировку запросов (tracing).
Никаких захардкоженных URL в коде.

2. Асинхронные события
Публикация события занимает одну строку:

await daprClient.PublishEventAsync(
    "pubsub",
    "booking-created",
    evt);

Подписчики обрабатывают события через атрибут [Topic].
Больше не нужен шаблонный код с BackgroundService.

3. Состояние приложения и кеширование
Хранилище типа key-value с подключаемыми backend'ами:

await daprClient.SaveStateAsync(
    "statestore",
    key,
    value);

Дополнительно:
↳ нужен TTL — передайте metadata;
↳ нужна оптимистичная блокировка — используйте ETag;
↳ backend может быть Redis, PostgreSQL или Cosmos DB.
4. Управление секретами
Больше не нужно хранить учётные данные в appsettings.

var secrets = await daprClient.GetSecretAsync(
    "secretstore",
    "payment-gateway");

В качестве backend можно использовать:
- Azure Key Vault;
- AWS Secrets Manager;
- HashiCorp Vault.
Код приложения остаётся одинаковым для всех окружений.

5. Распределённые блокировки
Взаимное исключение между экземплярами сервисов:

var lockResponse = await daprClient.Lock(
    "statestore",
    "room-101",
    "owner",
    30);

Например, это позволяет безопасно забронировать номер, даже если за него одновременно конкурируют три экземпляра сервиса.
Но главное преимущество Dapr — это то, что объединяет все эти возможности.
Каждое имя (pubsub, statestore, secretstore) привязано к YAML-компоненту.

Хотите заменить RabbitMQ на Kafka?
Достаточно изменить один YAML-файл.
Код приложения при этом остаётся без изменений.

👉 @KodBlog

Я до сих пор вижу эту ошибку в большинстве .NET API.

Эндпоинт принимает query-параметр, выполняет асинхронный запрос к БД и возвращает результат. На первый взгляд всё нормально. Но нигде нет CancellationToken.

Пользователь закрыл вкладку. Мобильный клиент словил таймаут. Load balancer разорвал соединение. А серверу всё равно. Он продолжает выполнять запрос, держит соединение, аллоцирует память и упорно считает результат, который уже никому не нужен.

Хотя .NET умеет это обрабатывать. Любой эндпоинт может принимать параметр CancellationToken, а фреймворк автоматически пробрасывает туда HttpContext.RequestAborted. Дальше просто передаёте токен в EF Core, HttpClient, file IO, channels — в любые async-вызовы. Как только запрос прерывается, операции останавливаются. SQL-запрос отменяется прямо во время выполнения. HTTP-вызов обрывается. Соединение возвращается в pool.
Два сценария, где это буквально разница между «система здорова» и «всё горит»:

Поток пользователей долбит медленный search-endpoint. Половина в ярости перекликивает UI и бросает запросы. Без токена сервер честно доводит каждый запрос до конца. С токеном брошенные запросы отменяются за миллисекунды, а pool остаётся доступен для тех, кто всё ещё ждёт ответ.

Долгий export падает на середине. Клиент делает retry уже с новыми параметрами. Без токена старый export продолжает молотить ещё две минуты, пока новый стоит в очереди за ним. С токеном разрыв соединения сразу освобождает worker.

Изменение — это всего два параметра: один в эндпоинте и один в методе доступа к данным. Всё.
Обычно в ответ слышу: «а что насчёт бэкграунд-задач, которые не должны отменяться?» Справедливо. Для них явно передавайте CancellationToken.None — и намерение сразу видно прямо в сигнатуре.
Каждый async IO-вызов в вашем коде должен принимать и прокидывать CancellationToken.

👉 @KodBlog

Не каждой real-time фиче нужен SignalR.
Иногда вам не нужен full-duplex communication. Не нужны hubs. Не нужна client library.
Нужно лишь, чтобы сервер пушил обновления в браузер.

Именно здесь отлично подходит Server-Sent Events (SSE).

SSE даёт простой однонаправленный поток от сервера к клиенту поверх обычного HTTP.
А в ASP.NET Core 10 наконец появился нативный high-level API.

Можно вернуть stream из IAsyncEnumerable, а .NET сам будет держать HTTP-соединение открытым:

return Results.ServerSentEvents(
    channelReader.ReadAllAsync(cancellationToken),
    eventType: "orders");

На стороне браузера всё так же просто. Без npm-пакетов. Без кастомного протокола.
Просто EventSource.

SSE также сразу даёт несколько полезных возможностей:
- автоматический reconnect в браузере
- стандартный HTTP middleware
- обычную authorization-модель
- простую фильтрацию по пользователям
- поддержку повторной отправки пропущенных событий через Last-Event-ID

Поэтому SSE отлично подходит для:
- notification bell
- dashboard’ов
- progress update’ов
- обновлений статуса заказов
- лёгких live feed

Но это не замена SignalR. Если нужен двусторонний обмен сообщениями, сложный scale-out или более богатый real-time protocol — SignalR всё ещё остаётся лучшим выбором.

Суть проще: Используйте самый лёгкий инструмент, который решает задачу.

👉 @KodBlog

Я собрал рабочий Minimal API с EF Core всего в 3 файлах.

То же самое можно сделать за 10 минут. Без solution-файла. Без csproj. Без настройки проекта.

Только три .cs-файла и dotnet CLI.

Это file-based apps из .NET 11 Preview 3.
И это полностью меняет подход к созданию внутренних инструментов и прототипов.

Структура из 3 файлов

Order.cs
↳ Обычный POCO с Id, OrderNumber, CustomerName, Amount, CreatedAt

OrdersDbContext.cs
↳ EF Core DbContext с inline Fluent API mappings

main.cs
↳ Настройка DI, Minimal API endpoints и app.Run()

Вот и всё: 3 файла в одной папке.

Вся магия — в 4 директивах в начале main.cs

#:sdk Microsoft.NET.Sdk.Web

↳ Подключает WebApplication и типы ASP.NET Core

#:package Microsoft.EntityFrameworkCore.Sqlite@10.0.0

↳ При первом запуске подтягивает SQLite provider

#:include Order.cs

↳ Добавляет entity в компиляцию

#:include OrdersDbContext.cs

↳ Добавляет DbContext в компиляцию

Эти четыре строки заменяют целый csproj и sln.
Ниже директив — обычный ASP.NET Core-код.

Запуск одной командой:

dotnet run main.cs

При первом запуске восстанавливается EF Core.
Все последующие запуски уже быстрые.
И в итоге у вас полноценный Web API с настоящей базой данных.

Где file-based apps особенно хороши
→ Internal tools без лишней церемонии
→ Прототипы, которыми можно делиться как одной папкой
→ Демо, запускаемые за пару минут
→ Замена Python-скриптов там, где нужна строгая типизация
→ Онбординг новых разработчиков без путаницы с csproj

Где их использовать не стоит
→ Multi-project решения с shared libraries
→ Приложения с кастомной MSBuild-логикой
→ Разработка NuGet-пакетов
→ Production-приложения с полноценным CI/CD и test-проектами

А когда скрипт перерастёт свой формат — есть команда миграции:

dotnet project convert main.cs

Она создаст полноценный csproj и перенесёт туда все директивы.

👉 @KodBlog

Опенсорс домен-сервис с 162K звезд,

→ Регистрация доменов за $0
→ Бесплатное продление навсегда
→ Никаких скрытых подписок и ловушек
→ Полностью open-source и управляется сообществом

https://github.com/DigitalPlatDev/FreeDomain

👉 @KodBlog

Большинство .NET-разработчиков используют Redis только как кэш — и на этом всё.

Redis хранит данные в памяти (RAM), а не на диске, поэтому чтение обычно занимает меньше миллисекунды.

Именно благодаря этой скорости Redis подходит не только для кэширования. Вот 10 сценариев, о которых стоит знать:

1. Кэширование ответов API

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

2. Хранение сессий

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

3. Ограничение частоты запросов (Rate Limiting)

С помощью одного счётчика Redis можно отслеживать количество запросов от IP-адреса за последнюю минуту и блокировать злоупотребления ещё до того, как они дойдут до API.

4. Лидерборды в реальном времени

Сортированные множества (Sorted Sets) позволяют автоматически поддерживать рейтинг по очкам. Запрос топ-10 выполняется практически мгновенно даже при миллионах игроков.

5. Обмен сообщениями через Pub/Sub

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

6. Распределённые блокировки

Когда несколько серверов могут одновременно изменять одну и ту же запись, Redis выдаёт единственную блокировку. Это помогает избежать конфликтов и перезаписи данных.

7. Очереди задач

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

8. Аналитика в реальном времени

Redis Streams позволяют записывать большие потоки событий (клики, просмотры страниц и т.д.) и обрабатывать их по мере поступления.

9. Флаги функциональности (Feature Flags)

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

10. Память для AI-чатов

Храните недавний контекст диалога в Redis, чтобы LLM (модель, лежащая в основе чат-бота) могла помнить, о чём шла речь ранее.

Один инструмент — десять сценариев использования. Но большинство команд так и остаются на первом пункте.

👉 @KodBlog

Разработчики на .NET, автоматизируйте работу с документами.

→ Генерация PDF-документов (QuestPDF / iText)
→ Экспорт в Excel без использования Interop (ClosedXML / EPPlus)
→ Объединение и разделение PDF-файлов (PdfSharp)
→ Работа с шаблонами Word (OpenXML / DocX)
→ OCR и извлечение данных из документов (PdfPig / Tesseract / Azure Document Intelligence)

Подробнее: https://buff.ly/65Hrxv4

👉 @KodBlog