Зачем нужна асинхронность в backend и как она помогает при работе с базой данных

Что проверяют

Понимаете ли вы, что асинхронность не ускоряет отдельный запрос к базе, а освобождает поток на время ожидания. Следом обычно спрашивают про .Result и .Wait(), про один DbContext в нескольких задачах или про пул соединений.

Как отвечать

Запрос к базе в основном состоит из ожидания: сеть, выполнение на сервере БД, передача результата. В синхронном коде поток из пула ASP.NET Core всё это время заблокирован. При await поток возвращается в пул и обслуживает другие запросы, а продолжение метода выполнится на свободном потоке, когда драйвер получит ответ. Время одного запроса не меняется, растёт пропускная способность: тот же сервер держит больше одновременных запросов без роста числа потоков.

Что стоит показать на практике:

• асинхронный путь целиком: OpenAsync, ExecuteReaderAsync, ReadAsync в ADO.NET, ToListAsync, SaveChangesAsync в EF Core и async по всей цепочке до контроллера;
• CancellationToken: принимать в экшене и передавать в каждый вызов. Если клиент ушёл, запрос к базе отменится, а не доработает впустую;
• параллельные запросы: Task.WhenAll уместен для независимых запросов, но у каждого свой DbContext или своё соединение. Один DbContext не потокобезопасен и на второй одновременной операции бросит InvalidOperationException;
• ConfigureAwait(false): в ASP.NET Core нет SynchronizationContext, поэтому в коде приложения он не обязателен, в библиотеках его ставят по-прежнему.

Назовите и предел: асинхронность не добавляет мощности самой базе. Пул соединений в SqlClient и Npgsql по умолчанию ограничен сотней, и под нагрузкой узким местом становятся он и сервер БД.

Где спотыкаются

Блокируют асинхронный код через .Result или .Wait(). Под нагрузкой потоки пула заканчиваются, новые добавляются медленно, и сервис замирает при почти пустом CPU. Это thread pool starvation.

Оборачивают синхронный вызов в Task.Run и считают код асинхронным. Блокировка просто переехала на другой поток того же пула.

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