Привет, Хабр. Меня зовут Любовь Вайгель. Я системный аналитик в СберЗдоровье — MedTech-компании №1 в России.
Во многих сценариях, сталкиваясь со снижением скорости ответа системы, компании приходят к необходимости внедрения кэша и довольно быстро реализуют кэширование на уровне технологий. Но правда в том, что кэширование, которое часто воспринимают как простой тактический приём для ускорения работы приложения, на практике может сильно изменить свойства системы: согласованность данных, поведение при сбоях, требования к актуальности и доступности информации. Поэтому для системного аналитика важно четко понимать, что мы кэшируем, зачем, на каких условиях и как это будет отражено в требованиях.
В этой статье я разберу пять неочевидных истин о кэшировании, которые часто остаются «за кадром», и покажу, как они влияют на работу системного аналитика.
1. Кэш — это распределённая система
Основная ошибка — воспринимать кэш как изолированный вспомогательный компонент. Как только в системе появляется кэш, у вас становится как минимум два источника данных:
основной источник истины — обычно база данных;
кэш.
То есть система начинает вести себя как распределённая. В результате появляется необходимость решать вопросы согласованности данных, порядка операций и распространения изменений. Именно поэтому простая на первый взгляд задача, такая как инвалидация кэша, быстро превращается в нетривиальную.
Например, вопрос «как кэш узнаёт, что данные изменились?» — это не техническая мелочь, а архитектурное решение, ведь возможны разные варианты, в том числе:
инвалидация по событию;
обновление по расписанию;
инвалидация по TTL;
комбинация подходов.
Для системного аналитика это означает простую вещь: в требованиях должна быть зафиксирована стратегия согласования данных между источником истины и кэшем. Если этого нет, поведение системы останется неуправляемым, а проблемы всплывут уже в продакшене.
Исходя из этого, в требованиях важно зафиксировать:
какие данные считаются источником истины;
когда и по какому событию кэш обновляется или инвалидируется;
что происходит, если кэш и основной источник временно расходятся.
2. Кэш ускоряет чтение, но усложняет согласованность данных
Кэширование всегда означает компромисс: мы ускоряем систему, но платим за это потенциальной неактуальностью данных и риском расхождения версий.
Причем расхождение может привести к разным последствиям, например:
пользователь видит устаревшие данные;
разные пользователи получают разные версии одной и той же информации;
система принимает решение на основе данных, которые уже изменились в источнике истины.
Важно отметить, что подобное расхождение не всегда критично — допустимость использования устаревших данных напрямую зависит от бизнес-контекста:
для каталога товаров устаревшее описание или рейтинг на несколько минут обычно терпимы;
для цены, остатка на складе, финансового баланса или медицинских данных требования к актуальности должны быть намного строже.
Поэтому задача системного аналитика — не просто проработать кэширование, а перевести этот компромисс согласованности в измеримые требования:
насколько свежими должны быть данные;
какая задержка обновления допустима;
в каких сценариях устаревшие данные недопустимы;
что пользователь или система должны увидеть, если данные могут быть неактуальны.
На практике это чаще всего выражается через требования к TTL, допустимому возрасту данных и сценариям, где кэш использовать нельзя.
3. Отказ кэша может обрушить всю систему
Существует распространённый миф: кэш — это необязательный компонент, и если он откажет, система просто станет медленнее.
В реальности в высоконагруженных системах отказ кэша может привести к полному падению приложения. Подтверждением этому является классический сценарий — thundering herd problem, при котором кэш становится недоступным или очищается и, как следствие:
множество параллельных запросов одновременно не находят данные в кэше;
все они идут напрямую в основной источник данных;
база данных получает лавинообразную нагрузку и тоже выходит из строя.
С технической стороны эту проблему часто решают с помощью паттерна Singleflight или аналогичных механизмов дедупликации запросов. Аналитику не обязательно выбирать конкретный механизм реализации, но важно зафиксировать требуемое поведение системы. Например:
одновременные запросы к одним и тем же данным не должны мультиплицировать нагрузку на источник истины;
при недоступности кэша система должна деградировать предсказуемо, а не создавать каскадный отказ;
критичные пользовательские сценарии должны иметь описанное поведение при отказе кэша.
Кроме того, требования к надёжности должны явно учитывать сценарий отказа кэша:
как система деградирует;
что происходит с пользовательскими запросами;
какие компоненты считаются критичными;
какие метрики и алерты нужны, чтобы заметить проблему до массового инцидента.
4. Иногда устаревшие данные лучше, чем их отсутствие
Это контринтуитивная, но важная идея: в ряде сценариев доступность важнее абсолютной актуальности.
Хороший пример — пользовательские ленты, списки, каталоги. Если сервис профилей временно недоступен, пустые блоки вместо имён и аватаров создают ощущение «сломанной системы», даже если формально данные просто не загрузились. Поэтому в таких случаях лучше показать немного устаревшие данные, чем не показать ничего.
Для этого используют резервное использование устаревшего кэша в пределах допустимого окна:
cacheTtl — время, в течение которого данные считаются актуальными;
fallbackTtl — время, в течение которого устаревшие данные допустимы как резервный вариант.
Если основной источник недоступен, система продолжает работать, отдавая данные из кэша, пока их возраст не превысил fallbackTtl.
Для аналитика это напрямую связано с требованиями к доступности и отказоустойчивости: где мы готовы пожертвовать свежестью данных ради пользовательского опыта, а где — нет.
Исходя из этого, в требованиях важно зафиксировать:
можно ли показывать устаревшие данные;
какой максимальный возраст таких данных допустим;
нужно ли сообщать пользователю, что данные могут быть неактуальны;
для каких сценариев fallback запрещён.
5. Кэшировать нужно не самые «дорогие», а подходящие данные
Часто можно услышать: «давайте кэшировать самые тяжёлые запросы». Стоимость получения данных действительно важна, но это не единственный критерий.
Хороший кандидат для кэширования обычно:
часто читается;
редко изменяется;
дорог в получении, например из-за сложных запросов или внешних API;
невелик по объёму;
имеет понятные правила актуализации.
Кэширование редко используемых или часто изменяющихся данных может не только не дать выигрыша, но и создать дополнительную нагрузку из-за постоянной инвалидации.
Поэтому в требованиях аналитик должен фиксировать не абстрактное «реализовать кэширование», а конкретный перечень данных или типов данных, которые подлежат кэшированию, и обоснование этого выбора.
Чек-лист требований к кэшированию для системного аналитика
Таким образом, перед тем как согласовывать кэширование, стоит ответить на ряд вопросов:
Какие данные кэшируем?
Где находится источник истины?
Какой допустимый возраст данных?
Что инвалидирует кэш?
Что происходит при недоступности кэша?
Можно ли отдавать устаревшие данные?
Как система защищает источник истины от лавинообразной нагрузки?
Какие метрики покажут, что кэш работает неправильно?
При этом ответы на эти и другие вопросы можно упаковать в полный и информативный набор требований. Например:
Требование к TTL. Система должна кэшировать данные профиля пользователя на 15 минут. По истечении TTL при первом запросе данные должны обновляться из основного хранилища.
Требование к инвалидации. При изменении пользователем аватара соответствующая запись в кэше должна быть немедленно инвалидирована.
Требование к отказоустойчивости. В случае недоступности основной базы данных система должна предоставлять данные профилей из кэша, если их возраст не превышает 60 минут.
Функциональное требование. В кэш должны помещаться следующие данные: профиль пользователя, список друзей, каталог товаров.
Требование к защите источника истины. При одновременных запросах к одним и тем же отсутствующим в кэше данным система должна выполнять не более одного запроса к основному хранилищу на ключ кэша за заданный интервал.
Такие формулировки позволяют избежать двусмысленностей и заранее определить поведение системы в критических сценариях.
Заключение
Кэширование — это мощный архитектурный инструмент. Оно почти никогда не ломает систему сразу: чаще всего это происходит позже — когда появляются расхождения в данных, каскадные отказы и неочевидные баги.
Именно поэтому без системного аналитика, который зафикисирует условия, ограничения и компромиссы, внедрить кэширование без ущерба всей системе в перспективе практически невозможно. При этом, для удобства работы с кэшем и учета всех ключевых аспектов, системные аналитики могут опираться на чек-лист, доступный по ссылке.
Если посмотреть на ваши текущие требования, какие из них стоило бы пересмотреть с учётом этих неочевидных истин?
