Кэширование почти всегда покупает скорость ценой рассинхронизации, инвалидации и более хрупкого операционного контура.
Глава сравнивает Cache-Aside, Read-Through, Write-Through и Write-Back через read-after-write semantics, cache miss behavior, stampede protection, recovery after failure и стоимость поддержки source of truth в нескольких слоях.
В архитектурных разговорах это помогает обсуждать cache placement, staleness tolerance и failure modes кэш-слоя как реальные design decisions, а не как автоматическое "давайте поставим Redis".
Практическая польза главы
Кэш как контракт
Проектируйте cache policy как часть продуктового контракта: что можно отдавать stale и где нужна строго свежая информация.
Инвалидация
Выбирайте схему инвалидации под бизнес-семантику: write-through, event-based, TTL или гибрид с версионированием.
Анти-шторм
Добавляйте защиту от stampede: jitter TTL, single-flight, background refresh и ограничение fan-out к origin.
Interview confidence
Демонстрируйте, что понимаете не только ускорение чтения, но и влияние кэша на консистентность и операционные риски.
Pattern
Cache-Aside Pattern
Классическое описание паттерна кэширования с практическими компромиссами.
Выбор стратегии кэширования определяет не только latency, но и границы консистентности, сложность recovery и поведение системы во время пиков. В продакшене обычно комбинируют несколько подходов: например, cache-aside для read-path и write-through для критичных сущностей с read-after-write требованиями.
Четыре базовые стратегии
Cache-Aside
Приложение само управляет чтением из cache и загрузкой из DB при miss.
Read Path
App
read(key)
Cache
GET key
DB
SELECT on miss
Cache
SET key
App
return value
Write Path
App
update(key)
DB
WRITE source of truth
Cache
invalidate/update key
App
ack
Что происходит
- Чтение сначала идет в cache; при miss значение загружается из DB.
- После miss приложение само прогревает cache для следующих запросов.
- Запись сначала в DB, затем invalidate/update cache для контроля stale-данных.
Риск: Критично не забывать invalidation, иначе растет stale-read rate.
Быстрый выбор стратегии
| Strategy | Read latency | Write latency | Consistency | Complexity | Best fit |
|---|---|---|---|---|---|
| Cache-Aside | Низкая на hit, выше на miss | Низкая (DB-only + invalidate) | Eventual (зависит от invalidation) | Низкая/средняя | General-purpose read-heavy сервисы |
| Read-Through | Стабильная через единый cache layer | Зависит от пары с write-policy | Зависит от write-side стратегии | Средняя | Платформенные cache-слои |
| Write-Through | Низкая | Выше (синхронная двойная запись) | Высокая после успешной записи | Средняя/высокая | Read-after-write критичен |
| Write-Back | Низкая | Очень низкая | Eventual, сложный recovery | Высокая | Write-heavy ingestion |
Практические правила
Что делать
- Фиксируйте SLA по staleness до выбора стратегии.
- Отдельно проектируйте cache invalidation и eviction policy.
- Для write-back используйте durable buffer + idempotent flush.
- Добавляйте protection от cache stampede (single-flight, jitter TTL).
Частые ошибки
- Кэшировать без явной стратегии invalidation и TTL.
- Использовать write-back для критичных финансовых данных без durable queue/journal.
- Кэшировать все подряд вместо focus на hot keys и дорогие запросы.
- Не учитывать stampede/thundering herd на массовом cache miss.
- Не считать hit rate, p95/p99 latency и stale-read rate.
Мини-чеклист по внедрению
Короткое правило выбора: если важнее предсказуемость и простота - начинайте с Cache-Aside; если критичен строгий read-after-write - смотрите в сторону Write-Through; если критичен write throughput и допустим eventual consistency - используйте Write-Back с надежным flush-контуром.
Связанные главы
- Принципы проектирования масштабируемых систем - задаёт базовые latency/cost trade-offs, в которых стратегия кэширования даёт основной выигрыш.
- Алгоритмы балансировки: Round Robin, Least Connections, Consistent Hashing - помогает понять, как key locality и распределение трафика влияют на hit rate и hot keys в кэше.
- Redis: обзор и практические аспекты - покрывает типичный runtime для кэш-слоя: TTL, eviction policy, persistence и operational ограничения.
- Service Discovery - показывает, как находить и обновлять пул cache-нод и backends для стабильной работы read/write-path.
- URL Shortener (caching strategy) - разбирает прикладной сценарий, где cache-aside и TTL прямо влияют на latency и стоимость запросов.
- CDN и cache invalidation - расширяет тему на edge-кэширование, purge/invalidation и многоуровневую cache-архитектуру.
- Multi-region / Global Systems - добавляет региональную репликацию и правила консистентности для кэшей между дата-центрами.