Гайд
Почему последовательные запросы одного ключа идут на один и тот же апстрим — и как это влияет на консистентность чтений.
Если каждый запрос независимо выбирает апстрим из пула, клиент может увидеть немонотонную картину мира: запросил eth_blockNumber, получил блок N, следующим запросом (например, eth_getBlockByNumber(N)) попал на узел, который ещё не догнал блок N, и получил «не найдено» — хотя с точки зрения клиента ничего не изменилось.
Запросы одного и того же ключа в пределах окна (настройка продукта) закрепляются за одним апстримом. Выбор апстрима для закрепления учитывает его латентность на момент закрепления, но не пересматривается на каждый последующий запрос — иначе привязка теряла бы смысл.
Если закреплённый апстрим перестаёт быть живым или отстаёт больше порога, привязка снимается и выбирается новый апстрим по обычному алгоритму.
В обычном сценарии (один клиент — один API-ключ на сервис) вам не нужно ничего делать: последовательные запросы уже консистентны в пределах окна. Если разные части вашей системы используют один ключ параллельно с высокой частотой запросов, учитывайте, что все они делят одну липкую привязку — это особенно заметно при превышении лимита частоты (RPS), который считается на весь ключ, а не на каждый отдельный вызывающий процесс.