Стандртно - очередью.

Верно. Если ресурс по определению единственный (а одна и та же дата - единственная), до доступ к нему - по очереди.

Тогда ты не можешь ничего сообщить клиенту - в вебе сервер только отвечает на запросы.

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

Для 1 - вероятно лучше всего сделать сигнал обновления с базы, а затем как то переслать всем у кого открыта страница с календарем signalR?

Если послал запрос, то есть таймаут на ответ. За этот таймаут должен оформиться заказ даты у конкурирующего пользователя и прислаться ответ с предложением выбрать другую дату. Если нагрузка настолько велика, что очередь на сервере не успевает отработать все одновременные заказы за время таймаута, то надо предусмотреть состояние ожидания ответа (состояние обработки запроса) - в этом состоянии клиент периодически шлёт запросы на сервер на результат ожидания.

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

ссылки говорят обратное

-----
Если клиент "слушает" - он уже сервер...

Внутри "слушания" вполне может быть обычный цикл, периодически опрашивающий сервер на предмет результата обработки запроса. Тогда сервер должен знать, что был запрос и его опрашивают о нём. Готовые библиотеки скорее всего просто всё это инкапсулируют с удобным программным интерфейсом.