Landing Hero — Cache-Aside

Overview

Классический cache-aside read паттерн: клиент тянет ленту, API сначала пробует Redis-кэш, при промахе идёт в Postgres и заполняет кэш на следующий запрос.

Components

• client — браузер пользователя, открывает GET /timeline
• api — Go/Node-сервис, отвечает за маршрутизацию и orchestration
• cache — Redis, TTL 30 секунд на ключ timeline:<user_id>
• db — Postgres, источник истины (tweets таблица)

Group frontend отделён от backend для наглядности — на проде эти ноды живут в разных VPC.

Scenarios

Cache miss read (тот, что играет в анимации):

1. [REQUEST] — клиент шлёт GET /timeline, попадает на API
2. [CACHE] — API дергает Redis на ключ timeline:42
3. [MISS] — Redis возвращает nil
4. [QUERY] — API делает SELECT * FROM tweets WHERE user_id=42 ORDER BY created_at DESC LIMIT 50
5. [ROWS] — Postgres возвращает 50 строк (≈80ms)
6. [FILL] — API кладёт результат в Redis с TTL 30s
7. [200 OK] — итоговый response клиенту (≈180ms total)

При последующих запросах в течение 30s шаги 4-6 пропускаются — латентность падает до ~10ms.

Tradeoffs / Failure modes

• Stale reads: до 30s окно несогласованности. OK для лент, не OK для балансов.
• Thundering herd: при истечении TTL много параллельных запросов одновременно пойдут в БД. Лечится SET NX на lock-ключ или ProbabilisticEarlyExpiration.
• Redis down: API должен прозрачно фоллбэчить в БД (graceful degradation), не возвращать 500.
• Write path: запись твита здесь не показана — на write инвалидация делается через DEL timeline:<user_id> или версионный ключ.

References