Сравнение: для API поиска по каталогу выбрать произвольные фильтры или ограниченный набор поддерживаемых условий — какой вариант безопаснее для масштабируемой системы?
Для масштабируемой системы безопаснее ограниченный набор поддерживаемых условий с явными лимитами. Такой контракт позволяет заранее оценить стоимость запроса, подобрать индексы, защитить хранилище от дорогих комбинаций и сохранить предсказуемое время ответа.
Произвольные фильтры дают клиентам больше гибкости, но фактически превращают API в язык запросов. Это усложняет оптимизацию, контроль нагрузки, кэширование и совместимость с изменениями схемы данных.
Потребность в гибком поиске возникает, когда один ресурс должен обслуживать разные клиентские сценарии: фильтрацию, сортировку, выбор полей и постраничную выдачу. Фиксированный набор методов для каждого варианта быстро приводит к росту числа endpoint’ов и дублированию логики.
Произвольные параметры выглядят естественным способом избежать такого роста. Однако вместе с гибкостью API начинает принимать запросы, стоимость которых трудно предсказать: фильтры могут не использовать индексы, сортировка может требовать обработки большого объёма данных, а комбинация условий — создавать тяжёлые планы выполнения.
Предположим, API каталога принимает фильтры по цене, категории, бренду, статусу, рейтингу и дате обновления, а также сортировку и выбор возвращаемых полей. Если разрешить любые комбинации без ограничений, клиент сможет сформировать запрос, который сканирует значительную часть хранилища или потребляет много памяти на сортировку.
Результатом становятся скачки задержки, конкуренция за ресурсы с критичными операциями, тайм-ауты и каскадные повторы со стороны клиентов. Даже корректный с точки зрения бизнес-логики запрос может оказаться опасным с точки зрения стоимости выполнения.
Слишком жёсткий контракт тоже создаёт проблему: для каждого нового сценария придётся менять API. Поэтому цель — не запретить гибкость полностью, а ограничить её заранее проверяемыми возможностями.
Следует объявить конечный набор поддерживаемых фильтров и сортировок. Для каждого условия нужно определить тип, допустимый диапазон, возможность сочетания с другими условиями и соответствующую стратегию доступа к данным.
Практический контракт обычно включает:
Важно проверять запрос до обращения к хранилищу. Валидатор должен отклонять неизвестные поля, недопустимые операторы, чрезмерное количество условий и несовместимые сочетания. Это не заменяет защиту на уровне базы данных, но не позволяет клиенту произвольно расширять область поиска.
Индексы следует проектировать под реальные и разрешённые сценарии, а не под все возможные комбинации. Если фильтр допускает несколько значений, нужно учитывать максимальный размер списка и влияние такого условия на план выполнения. Для дорогих операций можно использовать отдельный асинхронный API, предварительно рассчитанные представления или специализированное поисковое хранилище.
Полезно вводить бюджет стоимости запроса. Он может учитывать число условий, диапазон времени, необходимость сортировки, объём выбираемых данных и допустимый размер страницы. Такой бюджет не обязан точно предсказывать время выполнения, но должен отсекать заведомо опасные запросы.
Компромисс состоит в том, что ограниченный API хуже подходит для непредусмотренных аналитических сценариев. Их не следует бесконтрольно добавлять в транзакционный endpoint: лучше предоставить отдельный интерфейс с собственными лимитами, квотами и моделью хранения.
Кэширование также проще при ограниченном контракте: нормализуется конечное множество параметров и легче оценить кардинальность ключей. При произвольном языке запросов число вариантов быстро растёт, поэтому кэш может иметь низкую эффективность и потреблять память без заметного снижения нагрузки.
Каталог разрешал клиентам передавать любые поля фильтрации и сортировки. После добавления фильтра по нескольким атрибутам задержка некоторых запросов выросла, потому что хранилище не могло эффективно использовать существующие индексы. Увеличение числа реплик чтения снизило долю ошибок, но не устранило конкуренцию за ресурсы и повысило стоимость инфраструктуры.
Рассматривались три варианта. Полностью произвольный язык запросов сохранял гибкость, но оставлял проблему непредсказуемой стоимости. Индивидуальные endpoint’ы давали лучший контроль, однако быстро увеличивали поверхность API. Ограниченный каталог фильтров потребовал изменений клиентов, зато позволил связать поддерживаемые условия с индексами и лимитами.
Выбрали третий вариант: оставили наиболее востребованные фильтры, ограничили диапазоны и размер страницы, ввели стабильную сортировку и отклонение неподдерживаемых комбинаций. Для редких сложных выборок добавили отдельный асинхронный процесс. В результате транзакционный поиск стал предсказуемее, а аналитические сценарии перестали конкурировать с обычными запросами каталога.
1. Достаточно ли ограничить только количество результатов на странице?
Нет. Маленькая страница не делает запрос дешёвым: хранилище может сначала просканировать и отсортировать большой объём данных, а затем вернуть всего несколько записей. Нужно ограничивать саму область поиска, поддерживать подходящие индексы, контролировать сортировку и учитывать стоимость построения результата.
2. Почему произвольная сортировка опаснее, чем произвольный фильтр?
Фильтр может уменьшить объём данных, а сортировка часто требует обработать все записи, прошедшие фильтрацию. Если поле сортировки не поддержано индексом, хранилищу может понадобиться полная выборка промежуточного набора и сортировка в памяти или на диске. Поэтому список сортируемых полей обычно должен быть короче списка фильтруемых полей.
3. Можно ли решить проблему произвольных запросов только кэшированием?
Нет. Кэш уменьшает часть повторных вычислений, но не ограничивает первый дорогой запрос, не защищает от большого числа уникальных комбинаций и может скрыть рост нагрузки до исчерпания памяти. Кэширование полезно как дополнительный механизм после валидации контракта, лимитов и контроля стоимости выполнения.