Сравните пакетный API и серию одиночных запросов для массового чтения: какой компромисс определяет выбор?
Пакетный API обычно выбирают, когда нужно получить много независимых ресурсов: он уменьшает сетевые накладные расходы и число отдельных операций на границе сервисов. Цена этого выигрыша — более крупный запрос, сложнее обработка частичных ошибок, ограничения на размер пакета и риск увеличения задержки для отдельных элементов.
Выбор определяется балансом между стоимостью сетевых обращений, требованиями к задержке, размером ответа, независимостью ошибок и допустимой сложностью контракта.
Пакетные операции появились как ответ на проблему «болтливых» интерфейсов: клиенту приходилось выполнять множество небольших удалённых вызовов, каждый из которых нес накладные расходы на сеть, сериализацию, аутентификацию и планирование обработки.
С ростом распределённых систем эта проблема стала заметнее. Даже быстрый одиночный запрос может быть дорогим в совокупности, если клиенту нужно выполнить сотни таких обращений. Пакетирование переносит часть этой работы с сетевого уровня в одну операцию, но требует явно определить её семантику.
Предположим, клиенту нужно прочитать 200 профилей. При серии одиночных запросов каждый профиль обрабатывается независимо, но клиент создаёт много сетевых обращений и повышает нагрузку на шлюзы, балансировщики и сервис.
При пакетном запросе сетевых обращений меньше, однако один запрос может стать тяжёлым: ответ будет большим, обработка отдельных идентификаторов может завершаться по-разному, а повтор всего пакета из-за одной ошибки способен создать лишнюю нагрузку.
Неверный выбор приводит к разным последствиям. Слишком мелкие запросы увеличивают накладные расходы и вероятность исчерпания лимитов соединений, а слишком крупные пакеты ухудшают p99-задержку, повышают пиковое потребление памяти и усложняют повторную обработку.
Пакетный API объединяет несколько логически независимых операций в один транспортный вызов. Сервер принимает набор идентификаторов, выполняет чтение группой и возвращает результат, сопоставленный с каждым идентификатором.
Ключевой вопрос — является ли операция атомарной. Для массового чтения обычно полезнее частичный результат: найденные элементы возвращаются, отсутствующие помечаются отдельно, а временно недоступные можно отличить от действительно неизвестных. Требование «весь пакет либо успешен, либо отклонён» проще концептуально, но снижает полезность ответа и провоцирует повтор всей операции.
Контракт должен явно определить несколько свойств:
На стороне хранилища пакетирование может уменьшить число обращений, но не гарантирует пропорционального ускорения. Запрос на большой набор идентификаторов может привести к плохому плану, превысить лимиты параметров или создать всплеск чтения. Поэтому размер пакета обычно ограничивают, а сервер при необходимости разбивает его на внутренние подгруппы.
Серия одиночных запросов предпочтительна, когда элементы требуют разных политик доступа, имеют сильно различную стоимость обработки или клиенту нужны результаты по мере готовности. Она также упрощает независимые тайм-ауты и повторные попытки, но клиенту или промежуточному слою нужно контролировать параллелизм, иначе массовое чтение превратится в перегрузку сервиса.
Пакетный API не должен автоматически означать неограниченное увеличение квоты. Лимиты, тайм-ауты, трассировка и rate limiting должны учитывать фактическую стоимость пакета, иначе один запрос на тысячу элементов сможет обойти ограничения, рассчитанные на одиночные операции.
Мобильному приложению экрана рекомендаций нужно показать данные о 120 авторах. Изначально оно отправляло по одному запросу на каждого автора. Вариант с сохранением одиночных запросов давал простую семантику ошибок и позволял отображать готовые элементы сразу, но создавал много сетевых обращений и требовал ограничивать клиентскую параллельность.
Вариант с одним неограниченным пакетом сокращал число обращений, однако делал ответ слишком большим, усложнял повтор и создавал риск долгого запроса при медленной обработке одного автора. Кроме того, такой контракт было бы трудно безопасно использовать для других массовых операций.
Был выбран ограниченный пакетный API с частичными результатами и фиксированным верхним пределом размера. Клиент разбивал 120 идентификаторов на несколько пакетов, ограничивал число одновременно выполняемых запросов и повторял только временно неуспешные элементы. Это сохранило преимущество пакетирования, но не превратило один вызов в неконтролируемую операцию; итоговый эффект следует подтверждать измерениями задержки, размера ответа и нагрузки на хранилище.
Для массового чтения обычно нет: независимые элементы не требуют общей транзакции. Полезнее вернуть статус каждого элемента, чтобы отсутствие одного профиля или временная ошибка зависимости не скрывали успешно прочитанные данные. Атомарность оправдана только при явной бизнес-инварианте, когда частичный результат сам по себе недопустим.
Размер запроса влияет не только на тело HTTP-сообщения. Он определяет объём памяти для разбора и формирования ответа, длительность удержания ресурсов, количество операций в хранилище и размер записи в трассировке. Без верхнего ограничения один клиент способен создавать непропорционально дорогие операции, поэтому лимит должен быть частью контракта и сопровождаться понятной ошибкой превышения.
Повтор всего пакета неэффективен, если успешными были большинство элементов: он повторно нагружает сервис и хранилище. Контракт должен позволять различать постоянные ошибки, например отсутствие ресурса или запрет доступа, и временные ошибки, которые можно повторить. Если повтор отдельных элементов невозможен, серверу нужно обеспечить предсказуемую идемпотентную семантику либо клиент должен принимать риск повторной обработки.