Стратегия кеширования в распределённой системе

Условие

В системе применяется горизонтальное шардинг‑таблиц SQL‑БД с репликацией для повышения отказоустойчивости. Сформулируйте и спроектируйте подход к кешированию:

• Где разместить кеш‑слой (перед базой, в API‑шлюзе, внутри микросервисов)?
• Какие данные кешировать: сопоставление short_link → long_link, часто запрашиваемые записи, сроки жизни (TTL) и т.д.
• Какой тип кеша использовать: in‑memory (Redis, Memcached), локальный или распределённый?
• Какие стратегии управления кешем применять: TTL, LRU, write‑through, write‑around и прочие?
• Как гарантировать согласованность данных между кешем и базой?

Ответ

Для short_link → long_link подходит cache-aside перед БД внутри сервиса. TTL кеша не должен превышать expires_at самой ссылки.

Распределённый кеш уменьшает число чтений шардов, небольшой локальный L1 помогает самым горячим ключам, но усложняет инвалидирование. При промахе сервис читает нужный шард и кеширует результат; одновременные промахи одного ключа объединяют, а fallback ограничивают.

Для неизменяемых ссылок согласованность проще. При изменении или отзыве сначала фиксируют версию в БД и доставляют событие инвалидирования; старое чтение не должно вновь заполнить кеш прежней версией. Строгий немедленный отзыв может требовать проверки авторитетного состояния. Negative cache делают коротким. LRU ограничивает объём, но не заменяет TTL и проверку срока ссылки.