А может кто-нибудь пояснить, каким образом все эти асинхронные фреймворки умудряются держать тысячи подключений в рамках одного потока и при этом работать с файлами и базами данных? Ведь если я обращаюсь к файлу, или выполняю запрос к БД, то эта операция может длиться несколько секунд! В этом случае обмен со всеми подключениями замораживается? Или же в этих фреймворках под капотом имеются свои функции работы с файлами и базами данных, которые и не создают кучу доп. потоков и не замораживают поток, из которого произошёл вызов из контекста подключения (но при этом приостанавливают выполнение кода, который такую функцию вызвал)? Есть ли в них такие волшебные функции для работы с Firebird?

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

Не важно. Пусть будет main thread.

Не понял вопроса. Они с разных сторон бывают?

Мне интересна организация веб-сервера на асинхронном фреймворке, но чтобы он не просто hello world в ответ отсылал, но и запросы к бд делал, работал с файлами и обращался к другим микросервисам .

Наверное трехзвенка: Клиент (браузер) - Сервер - СУБД/микросервисы.

Допустим, 10000 клиентов по http решили одновременно отправить запрос на сервер. Сервер для обработки каждого из запросов обращается к СУБД. СУБД находится на другом компьютере на другой стороне земного шара (Ping = 100 мс). Из-за длительного пинга каждый запрос к СУБД условно занимает 1 секунду (хреновый случай, когда каждый запрос нужно предварительно препарировать, а это ещё куча лишних сетевых запросов). Вопрос: через сколько времени наши 10000 клиентов увидят ответы на свой запросы (например, при использовании RTC / ICS / mORMot)?
Если эти фреймворки асинхронные, то в идеале, они как-то должны уметь и с удалённой СУБД обменяться асинхронно, не плодя 10000 потоков лишь для ожидания ответа от СУБД.
Каким образом они будут ожидать ответа от удалённой СУБД?
а) асинхронно (например через порты завершения ввода/вывода). В этом случае не должны создаваться никакие лишние потоки, не затрачиваются лишние ресурсы (ОЗУ, вирт. память, процессор). Все клиенты увидят ответ одновременно (спустя 1 секунду). Однако в этом случае разработка сильно осложняется, т.к. мало того, что нам нужно писать асинхронный код обмена с клиентами, так ещё нужно писать асинхронный код обмена с СУБД.
б) асинхронно, но за счёт создания 10000 доп. потоков (лишь для ожидания ответа от СУБД). В этом случае, если программа 32-битная, то на создание 10000 потоков может не хватить виртуальной памяти. Значительные вычислительные ресурсы тратятся на создание большого числа потоков. В этом случае разработка также сильно осложняется, т.к. мало того, что нам нужно писать асинхронный код обмена с клиентами, так ещё нужно писать асинхронный код обмена с СУБД.
в) асинхронно, но за счёт создания пула из нескольких доп. потоков, например 100 (для ожидания ответа от СУБД). В этом случае, первые 100 счастливчиков получат ответ через 1 секунду, следующие 100 ещё через 1 сек и т.д. В этом случае разработка также сильно осложняется, т.к. мало того, что нам нужно писать асинхронный код обмена с клиентами, так ещё нужно писать асинхронный код обмена с СУБД.
г) тупо блокировать поток, в котором осуществляется обмен с 1000 клиентов. Это самый грустный вариант. Первый клиент получит ответ через 1 сек, следующий ещё через 1 сек и т.д., пока у клиентов не возникнет ошибка таймаута. Тогда уж лучше писать на Indy.

Это похоже на вариант б) или в)...

Всё то же самое и у Indy :)