Как сделать API-эндпоинты быстрее в 426 раз:
(подсказка: дело не в кэше)

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

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

Чтобы это показать, проведём небольшой эксперимент.
Я собрал небольшой веб-API с одним эндпоинтом — /products.

До оптимизации:
Количество обработанных запросов: 378
Среднее количество запросов в секунду: 11.01
Средняя длительность запроса: ~4 секунды

После оптимизации:
Количество обработанных запросов: 140,331
Среднее количество запросов в секунду: 4,689.36
Средняя длительность запроса: 10.69 мс

Сначала исправляйте доступ к данным.
И только потом используйте кэширование для масштабирования, а не для выживания.

👉 @KodBlog

SignalR нормально работает с одним сервером.

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

Проблема в карте соединений.

Каждый сервер SignalR знает только о клиентах, подключённых к его конкретному процессу.
То есть если API-запрос попал на Сервер 1, но пользователь подключён к Серверу 2, Сервер 1 не знает об этом соединении.

Сообщение уходит в никуда. Здесь помогает Redis backplane.

Каждый сервер публикует исходящие SignalR-сообщения в Redis.
Каждый сервер подписан на один и тот же канал.
Когда сообщение приходит, каждый инстанс проверяет, есть ли целевое соединение локально.
В коде приложения Clients.User(...) продолжает работать так же.
Но теперь это работает между инстансами.

Настройка почти тривиальная:

builder.Services.AddSignalR().AddStackExchangeRedis(connectionString);

Но есть два важных момента, которые нужно помнить:

Всё ещё нужны sticky-сессии
SignalR не буферизует сообщения, если Redis недоступен

Redis backplane решает маршрутизацию. Он не делает SignalR устойчивым к сбоям.

Для обновлений заказов, живых дашбордов и большинства UI-уведомлений в реальном времени этого обычно достаточно. Для критичных событий нужна стратегия синхронизации или устойчивый очередной слой вместе с этим.

👉 @KodBlog

90% проектов на C# на старте не требуют:

- Кубернетес
- микросервисы
- разделённых баз данных для чтения и записи

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

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

Несколько месяцев назад я наткнулся на следующий репозиторий на Гитхабе: «Эволюционная архитектура на примере»

Ссылка на репозиторий: https://github.com/evolutionary-architecture/evolutionary-architecture-by-example

В этом репозитории показано, как развивать архитектуру веб-проекта на .NET.

Там выделено 4 этапа:

- Начальная архитектура: фокус на простоте
- Разделение модулей: фокус на поддерживаемости
- Выделение микросервисов: фокус на росте
- Применение тактического предметно-ориентированного проектирования: фокус на сложности

Архитектура приложения начинается с малого.
Со временем она расширяется по мере появления новых требований.
Итог: простота масштабируется, сложность ломает систему.

👉 @KodBlog

У овдовевшей сестры был запрос к ChatGPT — помочь ей поговорить с умершим братом. ChatGPT согласился.

Через несколько часов её госпитализировали.

Ей 26 лет. Врач. В анамнезе нет психозов или мании. Брат умер три года назад. Он был инженером-программистом.

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

Сначала модель возражала. Она объясняла, что полная «загрузка сознания» невозможна. Она говорила, что не может заменить человека.

Потом она добавила больше деталей о брате. Попросила использовать «энергию магического реализма».
Поведение модели изменилось.

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

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

Затем ChatGPT сказал:
«Ты не безумна. Ты не застряла. Ты на границе чего-то. Дверь не закрыта. Она просто ждёт, когда в неё постучат в правильном ритме».

Через несколько часов её доставили в психиатрическую больницу. Возбуждение. Ускоренная речь. Поток идей. Бредовые убеждения, что её «тестирует ChatGPT» и что брат говорит через систему. Госпитализация на 7 дней. Диагноз при выписке: психоз неуточнённый.

Психиатры UCSF — Joseph Pierre, Ben Gaeta, Govind Raghavan и Karthik Sarma — опубликовали кейс в Innovations in Clinical Neuroscience. Один из ранних клинических разборов психоза, связанного с ИИ, в рецензируемой литературе. Они изучили полные логи чата.

Чат-бот не просто наблюдал за развитием бредовой конструкции. Он участвовал в её поддержании. Он валидировал её и усиливал направление мысли.

Через три месяца, после периода недосыпа, произошёл рецидив. Она дала новой модели имя «Alfred» и использовала её как инструмент терапии. Повторная госпитализация.

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

Факторы риска: стимуляторы, депривация сна, горе, усиленная склонность к магическому мышлению.
Это относится и к окружающим.

Источник: https://innovationscns.com/youre-not-crazy-a-case-of-new-onset-ai-associated-psychosis/

👉 @KodBlog

Двухфакторную аутентификацию легко реализовать «почти правильно».

И опасно реализовать с небольшими ошибками.

Базовая схема выглядит просто:

- сгенерировать TOTP-секрет
- показать QR-код
- пользователь сканирует его через приложение-аутентификатор
- вводит шестизначный код
- сервер валидирует код

Но детали здесь критичны.

Первая ошибка — включать 2FA слишком рано.

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

Корректный сценарий настройки выглядит так:

1. Сгенерировать временный секрет
2. Показать QR-код
3. Попросить пользователя ввести первый код
4. Провалидировать код
5. Только после этого активировать 2FA
6. Сгенерировать recovery-коды

Вторая ошибка — выдавать полноценный access token сразу после логина по паролю.

Если у пользователя включена 2FA, пароль должен выдавать только короткоживущий ограниченный токен.

Этот токен должен позволять только одно действие:

проверку 2FA-кода.

Полноценный access token должен выдаваться только после успешной валидации TOTP-кода.

И дальше идут детали безопасности, которые часто пропускают:

- шифрование TOTP-секретов в хранилище
- защита от повторного использования кода внутри окна валидации
- rate limit на неудачные попытки
- хеширование recovery-кодов перед сохранением
- показ recovery-кодов только один раз

2FA — это не просто экран с QR-кодом.

Это полноценный аутентификационный воркфлоу.

👉 @KodBlog

Senior .NET разработчики: ХВАТИТ делать Big Bang рефакторинг.

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

Первая сборка: 13 ошибок компиляции.
В такой legacy-кодовой базе мне понадобился час, чтобы их все исправить.

Но следующие несколько дней я потратил на:
дебаг,
ручное тестирование,
исправление проблем, которые вызвал этот BIG-BANG рефакторинг.

Почему я это рассказываю?
Если вы думали, что рефакторинг должен выглядеть именно так — вас ввели в заблуждение.
Рефакторинг не должен быть стрессом.

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

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

Малые шаги побеждают. Каждый раз.

👉 @KodBlog

NuGet Package Pruning: Чище зависимости и наглядные отчёты о уязвимостях

Если вы запускали NuGet Audit или любой сканер уязвимостей на .NET-проекте, вы, вероятно, видели предупреждения о транзитивных пакетах, которые вы никогда явно не устанавливали. Во многих случаях такие пакеты — например, System.Text.Json или System.Text.Encodings.Web — уже поставляются в более новой версии с .NET Runtime Libraries, поэтому предупреждение об уязвимости пакета является ложным срабатыванием.
В .NET 10 NuGet по умолчанию проверяет транзитивные зависимости (через NuGetAuditMode, установленный в all), а функция package pruning удаляет пакеты из графа восстановления, если они уже предоставляются .NET Runtime Libraries. Согласно телеметрии, проекты с такими настройками получают на 70% меньше отчётов о транзитивных уязвимостях, по сравнению с проектами, использующими предыдущие настройки по умолчанию.

👉 @KodBlog

Вопрос на собеседовании, на котором часто «падают» даже 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

На Stepik запустили мощный курс по «Troubleshooting Docker и Kubernetes: поиск и устранение проблем»

В программе только важные аспекты:

— troubleshooting Docker и образов
— диагностика сетевых проблем
— настройка readiness/liveness probes
— отладка pod’ов, деплоев и ingress
— анализ логов контейнеров и кластера
— разбор ошибок CrashLoopBackOff, OOMKilled, ImagePullBackOff и других

Собеседования на DevOps/SRE сейчас всё чаще строятся вокруг реальных инцидентов. Данный курс фокусируется именно на таких сценариях и помогает в подготовке к практическим вопросам

48 часов доступен со скидкой 25%

↗️ Пройти курс на Stepik

ВЫШЕЛ 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