C# .net Программирование

🚀 Опасен баг, который вылазит через 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&utm_medium=social&utm_campaign=05.01.2026

⚡️ В .NET кэш - это всегда выбор: максимальная скорость или единые данные между серверами. IMemoryCache ✅ Очень быстрый ❌ Работает только внутри одной ноды (в кластере из 10 серверов у вас 10 разных кэшей) Redis / IDistributedCache ✅ Один общий кэш на все ноды - данные одинаковые ❌ Медленнее: сеть + сериализация + лишние накладные расходы Правильный подход - Hybrid Cache. Он не заставляет выбирать - он комбинирует оба мира: - L1 (Local / RAM) - сначала читаем из памяти приложения (самый быстрый слой) - L2 (Distributed / Redis) - если локально нет, идём в общий кэш - Source (DB/API) - если нет и там, берём из источника и прогреваем оба уровня 🚀 скорость как у MemoryCache 🔒 данные согласованы между нодами как в Redis 📉 меньше нагрузки на БД и меньше «холодных» запросов Microsoft делает нативный HybridCache, но если нужно решение уже сейчас - FusionCache остаётся самым надёжным и реально продакшн-готовым вариантом. 📌 Гайд

🎯 Открытый урок «Сетевой чат на C#». 🗓 22 января в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «C# Developer». На вебинаре: ✔️ Рассмотрим написание сетевого приложения на C#. ✔️ Мы реализуем простые клиент и сервер с помощью одного из сетевых протоколов. ✔️Также затронем темы многопточности и асинхронности Кому будет полезно: • Вебинар будет полезен начинающим разработчикам, желающим разобраться в сетевом и многопочном\асинхронном программировании. Что вы получите: • По итогам вебинара смогут проектировать сетевые приложения. • Получат представление о работе сетевых протоколов, и многопоточности\асинхронности в приложениях. • На практике попробуют разработать такое приложение. 🔗 Ссылка на регистрацию: https://otus.pw/zifo/?erid=2W5zFJaPXHA Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

#ПятничныйКвиз

Не все стратегии балансировки нагрузки одинаково полезны. Если ты используешь 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: https://milanjovanovic.tech/blog/horizontally-scaling-aspnetcore-apis-with-yarp-load-balancing?utm_source=X&utm_medium=social&utm_campaign=05.01.2026 А какая стратегия у тебя стоит по умолчанию?

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

.NET 9 стал гораздо устойчивее к сбоям 💪 В .NET 9 появились официальные пакеты для отказоустойчивости: - Microsoft.Extensions.Resilience - Microsoft.Extensions.Http.Resilience Они построены поверх Polly, поэтому API знакомый - легко описывать политики: - retry - circuit-breaker - fallback - timeout - hedging - rate limiter Подключаете и ваши HTTP-клиенты и сервисы автоматически восстанавливаются при сетевых ошибках и таймаутах. Итог: меньше падений и больше стабильности. Отлично для продакшена 🚀