🚪 5 стратегий кэширования

Шпаргалка от Bytebytego показывает, как распределяется работа с данными между приложением, кэшем и базой данных, и как это влияет на скорость работы системы и актуальность информации.

💬 Application
— сервис, который обслуживает запросы.

Именно он решает: читать из кэша или БД, и как синхронизировать данные (в зависимости от выбранной стратегии).

💬 Cache
— быстрый слой (например, Redis/Memcached).

Держит «горячие» данные рядом с приложением, чтобы снижать задержку на чтении и разгружать БД.

💬 Database
— источник истины для данных.

Хранит полные и долговечные данные, но доступ к ней обычно медленнее и дороже по нагрузке, чем к кэшу.

💬 Cache Aside (Lazy Loading)
— приложение читает кэш, если нужных данных там нет, оно идёт в БД, забирает результат и само кладёт его в кэш.

Кэш заполняется по факту запросов. Просто внедрять, но при отсутствии данных в кэше получается цепочка запросов и возможна устаревшая информация, если БД обновили в обход приложения.

💬 Read Through
— если кэш не содержит запрошенных данных, то он сам, используя встроенный механизм, обращается к БД, заполняется и возвращает результат приложению.

Логика приложения упрощается, но усложняется кэш (нужен механизм/плагин, чтобы кэш умел получать данные из БД).

💬 Write Around
— запись сразу в БД, кэш не обновляется; кэш наполнится позже через чтения.

Подходит для данных, которые после записи редко читают. Минус — кэш может долго не содержать актуальных значений, и первые чтения будут уходить в БД.

💬 Write Through
— запись идёт в кэш, а кэш сразу синхронно пишет в БД.

Кэш и БД остаются согласованными, но запись становится медленнее: операция считается успешной после фиксации в БД.

💬 Write Back (Write Behind)
— запись идёт в кэш, а в БД — асинхронно и «пачками».

Даёт очень быструю запись и разгружает БД, но повышает риск потерь при сбое кэша и усложняет восстановление/контроль доставки в БД.

#полезное