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-контуром.