4rps это константа, на которую не повлиять

нет, он только на входящие.

но коннектор и обработка 429 мне больше нравится :)

это позволит динамически изменять пропускную способность, если вдруг на стороне принимающего сервиса увеличится количество RPS. и конечно если 429 не превращается в многоминутный бан

я давно об этом думаю, но как бы мне не хотелось, так лучше не делать. Было вычислено и подтверждено поддержкой, что сервайс вендора какое-то время находится в дауне, при этом не переставая получать входящие изменения об остатках. Принимает, но не процессит. А когда запрашиваешь остатки то он отдает их не актуальные. и потому если нам нужно посчитать какой-то накопительный итог, то данные могут обновиться прошлым периодом. И если мы в прошлом периоде эти данные уже получали, то доверять им нельзя.

429 превращается в " аналог бана", по достижению 5к запросов в час. И нужно ждать следующего часа
Да...да...вендор очень любит своих юзеров.

какой прекрасный вендор :)

из-за навалившихся задач по интеграции и поддержке этого дела пришлось погрузиться в давно пыляющуюся "высоконагруженные приложения" Мартина Клеппмана
и думая об этой задаче, все больше приходит на ум слово ESB, или кролик...но до бестпрактис пока руки не дошли. Потому и прошу совета)

очень хочется какой-то управляемый барабан, который всем запросам будет задавать темп

Спасибо тебе друг, за то что думаешь как я).
Тоже думаю, что это самое лучше решение и одно из самых простых в реализации и поддержки.

Реактивные микросервисы на 1С, ага, ты сделал мой мой день.)

Ребята, то что написано здесь - это так всегда было?

да

да, еще в разработке управляемого интерфейса было об этом написано

было - да. было ли написано в стандарте - не помню такого :)

в РУИ было точно

Век живи - век учись

Это же справедливо для табличных частей? Это же ведь тоже данные формы коллекция?