Как правильно кешировать запросы в Node.js REST API чтобы не положить базу

[nina_pixel]

Проблема: REST API на Node.js + Express + PostgreSQL. Один эндпоинт — тяжёлая аналитическая выборка, иногда до 3 секунд. Пользователей немного (~200 одновременно), но они долбят этот эндпоинт часто, у некоторых страница перезагружается каждые 30 секунд. База начинает задыхаться. Пробовал добавить Redis, но не понимаю правильную стратегию — когда инвалидировать кеш, как не отдавать протухшие данные.

[nikita_stack]

Для аналитических запросов с допустимой задержкой данных (а 30-секундный polling это явно допустимая задержка) — TTL-кеш в Redis это правильное решение. Ставишь TTL равным тому периоду за который данные допустимо устаревают. Если данные обновляются раз в 5 минут — TTL 5 минут. Простая схема: hit кеша — отдаёшь из Redis, miss — идёшь в базу, пишешь в Redis, отдаёшь клиенту. Сотни параллельных запросов превращаются в один запрос к БД каждые N минут.

[luka_crypto]

Есть нюанс который называется cache stampede — когда TTL истекает и 50 запросов одновременно идут в базу. Решается через lock или через паттерн stale-while-revalidate: отдаёшь устаревшие данные сразу, в фоне обновляешь кеш. В node.js можно реализовать через simple-lru-cache или через Redis SET NX для distributed lock. Для 200 пользователей это не критично, но знать полезно.

[luka4904]

Смотрел на твою схему — polling каждые 30 секунд это само по себе антипаттерн если данные меняются редко. Рассмотри Server-Sent Events или WebSocket с push-уведомлениями только при изменении данных. Меньше нагрузки, более актуальные данные, меньше головной боли с кешем. Node.js для этого отлично подходит.

[sqlreact9621]

Конкретная реализация для Express + Redis (ioredis): пишешь middleware который по ключу (url + query params) проверяет Redis, если есть — res.json(cached), если нет — next() и в конце обработчика вызываешь redis.setex(key, ttlSeconds, JSON.stringify(result)). Ключ кеша важно делать детерминированным, иначе один и тот же логический запрос будет разными ключами. Ещё момент: не забудь что Redis хранит строки, JSON.parse/stringify обязателен.

[liza_vue7]

А ещё посмотри на сам запрос — 3 секунды это очень долго. EXPLAIN ANALYZE в Postgres покажет где узкое место. Скорее всего не хватает индексов или нет материализованного представления для агрегатов. Кеш это хорошо, но если запрос можно ускорить до 100ms — часть проблемы уйдёт сама.