❗️ Готовим кэш правильно!

📈С ростом нагрузки одни и те же запросы к БД становятся узким местом.
Кто обитает на дне океана🤨 поможет нам в такой ситуации?

❗️Кэш!
Ставим рядом с приложением и базой:
⁍ Горячие данные под рукой
⁍ В БД ходим только при необходимости

❓ Следующий вопрос - как правильно с ним взаимодействовать?
С новым элементом приходят три независимых вопроса:

∙ Как читать?
∙ Как писать?
∙ Как инвалидировать данные?

Для конкретной задачи - это три независимых выбора.
Правильный ответ зависит от приоритетов: консистентность, скорость, простота.

👩🏻‍🦰👨🏻‍🦰 Пример: профиль пользователя
Профиль читается очень часто, почти при каждом запросе (аватарка, имя, настройки). Меняется редко. Пользователь обновил данные в настройках. После изменения новое значение должно быть видно сразу.

1) Чтение. Выбираем паттерн Cache-Aside.
➕ Простая реализация: достаточно Redis и нескольких строк кода, без сложной обвязки.
➕ Устойчивость к падению кэша: если Redis недоступен, приложение продолжает работать через БД.
➖ Первый запрос к "холодному" ключу приводит к cache miss: запрос идёт в БД и только потом прогревает кэш.
2) Запись. Выбираем паттерн Write-Through.
➕ После успешной записи данные в кэше и БД сразу синхронизированы.
➕ Одна точка обновления: не нужно отдельно думать об инвалидации при записи.
➖ Запись медленнее: оплачиваем и кэш, и БД. Для частых записей это может быть критично, но у профиля записи редкие.
3) Инвалидация. Выбираем TTL (например, час).
В данном случае стратегия записи Write-Through обеспечивает актуальность данных в кэше. TTL можно добавить для автоматической очистки ключей по истечении времени жизни.

✍️ Вывод
У кэша нет "правильного" паттерна на все случаи.
Есть три направления: чтение, запись, инвалидация. Под каждую задачу собирается своя комбинация.