Весь вопрос на сколько таймер ставить? мало поставить - создастся очередь событий из сработавших таймеров. Много поставить, все это будет ждать лишнее время, и зачем тогда возились с оптимизацией?
Опять же где то надо хранить запросы, которые пришли, но не могут быть выполнены в момент прихода

Если вы писали, что буфер на десятки тысяч (т.е это столько запросов, которые в данный момент выполняются / 2) , и даже больше, а в 99% случаев там нет участников очередного запроса, то на сколько же участников рассчитана эта система?

С чего это создастся очередь событий таймеров?) Сервер просто отправит сообщение браузеру типа "Щас не могу, попробуй попозже". На браузере принимается ответ и ставится таймер. По времени не более 1 секунды — иначе пользовательский UX начнет страдать. Оптимально 250-500 мс. Этого времени должно быть более чем достаточно, чтобы buffer освободился для ожидающего участника, т.к. операции выполняются мгновенно.

Опять же, вы забываете учитывать факт того, что это во всех случаях исключение, а не стандартный процесс.

Если бы участникам приходилось каждый раз ожидать, то здесь очевидно было бы реализация очереди. Но в 99,9999% случаев им ждать совершенно не придётся.

У меня сейчас такое впечатление складывается, что с внедрением очереди можно только навредить. Нет очереди — нет проблем.

Было сказано, что в буфер может добавляться до 30 тысяч участников в секунду — и это только на данный момент, в будущем пропускная способность может быть увеличена (есть зависимость от используемого алгоритма проверки).

А про реальную нагрузку было сказано, что это должно обрабатывать в районе не менее 1500 участников в секунду.

И заново отправляет тот же запрос? А потом в случае чего опять заново...
Во первых лишняя нагрузка на сеть, туда сюда гонять запросы с ответами, что выполнить не может. Нагрузка на сервер - получать лишние запросы, которые уже были.
Возможна такая ситуация, что пользователь А хочет что то передать С,
но идет много других запросов с С, которые по несчастливой случайности обрабатываются первыми, пока А сидит с timeout-ом. И он все сидит, сидит, запросы все идут и отклоняются.

Чем плоха очередь на сервере, я так и не понял.
Но вам виднее, я всей задачи не знаю.

Вы правы. Этому есть место быть.

Получается надо общую очередь всех запросов изначально хранить? Такая логика?:

1. На сервер поступают запросы и помещаются в pool

2. Из pool операции добавляются в buffer и удаляются. Если в buffer не может добавиться, то перемещается в конец pool

Так?

Не совсем.
pool - это не совсем очередь. Добавляется только в конец. А выбирается при просмотре от начала до конца все операции, которые могут быть выполнены.
Просмотр пула делается так
Берем операцию.
Проверяем, может ли она быть выполнена (участников нет в буфере).
Если может, то отправляем операцию на выполнение. При этом ее участники добавляются в буфер.
Берем след. операцию из пула
и т.д.
Т.е добавляем мы только в конец, а взять можем откуда угодно, просматривая пул. При этом взятая операция, конечно, удаляется из пула.

Просмотр пула инициируется при двух событиях:
- Новая операция добавлена в конец пула,

- Выполнилась какая то ранее отправленная на выполнение операция. При этом ее участники удаляются из буфера.

Такой алгоритм я предлагаю.

Получается что общая очередь всех операций не нужна?

Ваще так всё и предполагалось делать. Оставался вопрос лишь в реализации. Думаю для этого отлично подойдёт Map() с автоинкрементом по ключу.

Следующий найти будет трудно, если мы изъяли какие то после текущего.
Придется в цикле ключи перебирать.
И как взять первый? Перебрать все и найти минимальный?