Caching & Redis
Тема дорожной карты · DevOps Engineer
Кэширование сохраняет результаты дорогих операций — запросов к БД, вызовов API, отрендеренных страниц — ближе к потребителю, чтобы повторные запросы получали ответ без повторной работы. Redis — фактический стандарт in-memory хранилища, используемого как кэш, с опциональной персистентностью, pub/sub и примитивами вроде вытеснения LRU/LFU, ключей с TTL и атомарных счётчиков. Сложности — инвалидация кэша, выбор политики вытеснения и предотвращение «лавин» при одновременном промахе многих клиентов.
Как это работает
Caching & Redis — инженерная практика поддержания данных доступными, сохранными и восстанавливаемыми при сбоях. Инструментарий: реляционные БД (PostgreSQL, MySQL) с primary/replica-репликацией, point-in-time recovery через WAL archiving; кэш-слои (Redis, Memcached) для горячих чтений; backup-стратегии (pg_dump, pgBackRest, WAL-G, Velero для Kubernetes PV); high-availability паттерны (Patroni для Postgres, Sentinel для Redis); runbooks disaster recovery с RPO/RTO-целями. Capacity planning — это нагрузочное тестирование (k6, Locust) и прогнозирование роста по реальному трафику.
Когда применять
Инвестируйте в Caching & Redis с момента появления платящих пользователей или бизнес-критичных данных. Порядок: ночные бэкапы, проверенные ежеквартальными restore-drill'ами → репликация (sync или async) → automated failover → multi-region replication для серьёзных RPO. Не пропускайте restore-drill — бэкап, который никто не восстанавливал, — это отсутствие бэкапа. Для SaaS ₽249/мес как devroadmap.ru минимальная планка — один Postgres + ежедневный pg_dump в object storage с 7-дневным retention; HA-схемы преждевременны до контрактных SLO по uptime.
Типичные ошибки
Ловушки reliability: непроверенные бэкапы (классика — backup-скрипт "успешен", но дамп corrupted); replication lag, который никто не мониторит, пока replica не отстанет на 4 часа; manual failover, который никто не репетировал; Redis как "база" вместо кэша (по дефолту эфемерный); нет задокументированных RPO/RTO (узнаете на собственной шкуре после инцидента); cap-сюрпризы (БД упирается в 100% CPU на Чёрной пятнице, потому что никто не нагрузил). Game days — ежеквартально.