Кэширование

Работал с кэшированием на нескольких уровнях:

HTTP / браузерный кэш;
серверный application cache;
Redis как backend для cache и lock-механизмов;
build-time кэширование;
локальный in-memory cache на frontend;
кэширование идемпотентных и условно-повторяемых запросов.

Серверное кэширование

Есть опыт прикладного кэширования данных и готовых ответов на уровне backend.

Что использовал на практике:

кэширование JSON-ответов в Redis;
revision-based invalidation;
ETag и условные запросы;
выборочное кэширование публичных и пользовательских списков;
разделение payload cache и revision key;
инвалидацию кэша при изменении данных.

Использовал revision-based схему для Redis JSON response cache:

публичные списки кэшируются с ETag и 304 Not Modified;
пользовательские списки тоже имеют отдельную схему кэширования;
при изменении данных ревизия увеличивается, и старый кэш становится неактуальным без грубой очистки всего store.

HTTP caching: ETag и conditional requests

Реализовывал HTTP Conditional Requests для API и файловых ответов.

Что обычно настраивал:

ETag;
Cache-Control;
304 Not Modified при совпадении условия;
разделение публичного и приватного кэширования;
безопасное поведение для изменяемых и чувствительных данных.

На практике это использовалось, например:

для index/list endpoint-ов с условной отдачей данных;
для списка сохранённых пользователем сущностей;
для файловых/изображений endpoint-ов с ETag и cache headers.

Revision-based invalidation

Есть опыт более аккуратной инвалидации кэша, чем простое удаление всех ключей.

Подход, который использовал:

отдельный revision key для группы данных;
payload cache keys в Redis, завязанные на текущую ревизию;
bump revision при изменении данных;
прикладные invalidator-классы и команды для управления инвалидацией.

Использовал отдельные invalidator-реализации и artisan-команду для bump revision у публичного списка рецептов.

Redis как cache backend и distributed locks

Использовал Redis как инфраструктурный backend для cache-механизмов.

Что обычно использовал:

хранение кэша;
lock-механизмы;
временные ключи с TTL;
служебные данные для антидублей и координации конкурентных запросов.

Redis может участвовать в двух разных ролях:

инфраструктурный state: sessions, queues, rate limiter, locks и idempotency/replay keys;
ручной HTTP-cache: revision-based payload cache для отдельных GET endpoint-ов вроде списков рецептов и сохранённых рецептов.

Idempotency и replay cache

Есть опыт использования кэша не только для ускорения чтения, но и для обеспечения корректного поведения write-операций.

Это выражается через idempotency middleware, которое:

строит cache key по idempotency key + запросу + identity;
хранит успешный ответ в Redis;
возвращает cached replay для повторного запроса;
использует lock и in-progress markers, чтобы не допускать конкурентную повторную обработку одной и той же операции.