Доброго времени суток, уважаемые хабровчане! Я живу в Ташкенте.

Как превратить беспокойство о качестве воздуха в полезный Open Source проект?

В этой статье я покажу, как с нуля подключить OpenTelemetry в ASP.NET Core проект и получить полноценную наблюдаемость: распределённые трейсы, метрики и логи. Мы не будем углубляться в теорию (что такое спаны/трейсы/метрики и почему это важно) - сфокусируемся на практике.

Мы развернём небольшой "микросервисный" стенд в Docker Compose и после пары запросов увидим в SigNoz полный набор сигналов: трейсы, метрики и логи с корреляцией по trace_id. Все исходники доступны в репозитории GitHub так что каждый шаг можно повторить самостоятельно.

Асинхронное программирование сегодня используется почти везде — от пользовательских интерфейсов до серверных систем с высокой нагрузкой. Оно позволяет не блокировать поток выполнения и эффективно работать с операциями ввода-вывода. Но вместе с этой гибкостью появляется и обратная сторона: пересекающиеся асинхронные вызовы начинают конкурировать друг с другом.

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

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

Более системный подход — объединять пересекающиеся асинхронные операции. Если несколько вызовов требуют один и тот же результат, нет необходимости выполнять работу несколько раз. Гораздо разумнее выполнить её один раз и распределить результат между всеми ожидающими.

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

В этой статье я разберу пять стратегий Async Coalescing — подхода, который позволяет контролировать конкуренцию асинхронных операций. Мы посмотрим, в каких ситуациях каждая стратегия полезна и какие компромиссы она вносит в систему.

Недавно я посвятил время проблеме производительности на продакшене. Приложение работало в горячке — загрузка процессора в среднем превышала 50% и периодически подскакивала до 90%. Мы сделали диагностический снапшот и начали работать с топом запросов по процессорному времени.

Нарушитель номер один? Простой запрос Dapper. Незамысловатое условие WHERE по проиндексированному столбцу. Должно было быть молниеносным, но в среднем потребляло тысячи миллисекунд процессора при сотнях тысяч выполнений в день.

Несоответствие типов на пару символов, совсем невидимое в C#‑коде. Я очень долго глазел на запрос, прежде чем понял происходящее.

В этой статье я постарался собрать краткий гайд по Singleton, Transient и Scoped. Статья рассчитана на тех, кто хотя бы немного знаком с DI в .NET и не является полноценным туториалом.

Эта статья скорее всего будет полезна тем, кто продолжает разбираться или работать на платформах .NET . Предупреждаю! Здесь будет далекое плавание в разные места, и с точки ОС будет упомянуто достаточно много!

На просторах Хабра есть несколько хороших статей про устройство и поведение .NET. Мне хотелось бы стать "чем-то по связующим" между ними.

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

Давайте представим, что вам нужно создать класс для хранения данных пользователя. Сколько строк кода вы напишете? Конструктор, свойства, метод ToString(), сравнение объектов... А если добавится новое поле? Придется обновлять конструктор, метод Equals, GetHashCode — утомительная работа, которая не добавляет бизнес-ценности вашему приложению.

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

В этой статье мы заглянем под капот CLR (Common Language Runtime) и разберём как хранятся разные типы данных. Также поговорим о том, что такое стек и куча, и как они взаимодействуют. И в заключении рассмотрим, как происходит выделение памяти и разберем принципы работы сборщика мусора.

Проектируете REST API и всё ещё используете 200 OK для ошибок?

А знаете, почему неправильные статус-коды могут убить производительность и как всего один кейс с TSB Bank показал цену плохого анализа?

В этой статье разбираем реальные принципы REST, модель зрелости Ричардсона.Полезно всем, кто пишет бэкенд или проектирует микросервисы.