Vlasenko Fedor, ну например возможно jsonplaceholder держит только три соединения, а больше - дропает.)
Частая ситуация, так-то.

Aetae,
сервер для одного клиента ?
для чего тогда балансировщики
и что делать с ошибками в таком случае?

Vlasenko Fedor, ты странный. Обычная антиспам\ антидос\ антибрутфорс система. На эндпоинт один клиент может послать только N запросов за раз. Это буквально везде.
Балансировщики - балансируют разные запросы разных клиентов меж разными серверами, они тут не причём.
С ошибками делать то же что и всегда - как-либо обрабатывать.

Пишешь, о том в чем не разбираешься
Ибо в эти системах есть понятие время в количество запросов, а не колличество только
Потому я изадал вопрос ТС, чтоб он пояcнил зачем это
Пример http://nginx.org/ru/docs/http/ngx_ht...eq_module.html

Vlasenko Fedor, што?
Вот прямо по твоей ссылке: ставим
limit_req zone=one burst=3 nodelay;
получаем именно такой результат.

"N запросов за раз" - очевидно очевидно значит "N запросов за минимальный промежуток времени установленный на сервере в подавляющем большинстве случаев равный одной секунде". Ты думал я о планковских величинах тут говорю, или что?

Aetae,
неужели непонятно, что лимит запросов идет по времени
давй на пальцах, как ты поймешь что превышен лимит ?
будешь считать запросы и говорить, что 4 уже с 503 ответом?
нет ты будешь смотреть в каком интервале времени прошли запросы
вот ответ на твой пример

Vlasenko Fedor, Эти фразы друг другу не противоречат: "будешь считать запросы на интервале времени rate(который в 99% равен 1r/s) и говорить, что 4 уже с 503 ответом". Одна секунда и есть условно одновременно.

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

Я же не про то, что все элементы заполнены, а с точки зрения оптимизации. Я ориентируюсь в этом на V8, как самый распространенный (это и Chrome, и Edge, и Node).

https://v8.dev/blog/elements-kinds
Конкретнее
https://v8.dev/blog/elements-kinds#avoid-creating-holes

Если массив стал (изначально создан) дырявым, то он дырявым и останется, что с ним не делай. V8 будет считать его дырявым, и не применять к нему оптимизаций, как к заполненному.
Я когда то делал тесты. Выигрыш может и не самый впечатляющий - 5-7%. Но все таки выигрыш.

voraa, ну это прям наносекунды. Тогда и методы массива вообще юзать не надо - просто циклы. Конечно же никакого spread и destructuring. А ещё можно выиграть на создании объектов вот так, да: https://v8.dev/blog/cost-of-javascript-2019#json .)