Теги кэша Cloudflare для SaaS-дашбордов без полного очищения

Почему полный purge раздражает всех клиентов

Полное очищение кэша кажется аккуратным решением. Один раз нажал — всё очистилось, а следующий запрос получил свежие данные.

Но в SaaS-дашборде такой короткий путь часто создает проблему больше той, которую вы пытались исправить.

Когда вы очищаете весь edge-кэш, вы не убираете устаревший контент только для одного тенанта. Вы одновременно выбрасываете теплый кэш для всех тенантов. Страницы, которые минуту назад открывались быстро, теперь должны заново собираться с origin — по одному тенанту и по одному маршруту за раз.

Пользователи это замечают сразу. Дашборд, который обычно открывается мгновенно, начинает подтормаживать. Графики появляются с задержкой. Навигация ощущается вязкой. Люди думают, что что-то сломалось, даже если данные технически правильные.

Замедление не остается у того клиента, который что-то изменил. Один администратор обновляет логотип, правило выставления счетов или настройку аккаунта, а расплачиваются за это все остальные. Компания в другом регионе с другими данными и без свежих изменений все равно получает тот же холодный кэш.

Именно здесь команды чаще всего попадаются врасплох. Им кажется, что они очистили одну проблемную страницу, а на самом деле создали всплеск лишней работы для origin и более медленный продукт для всех. Если трафик высокий, эффект быстро распространяется, потому что многие пользователи одновременно запрашивают одни и те же некэшированные страницы.

Сначала это обычно слышит поддержка. Клиенты не говорят: «у вас был очищен кэш». Они говорят, что дашборд внезапно стал медленным, отчеты открываются вечность или приложение сегодня работает странно. Такие жалобы сложно разбирать, потому что к моменту, когда кто-то смотрит графики, система может уже снова выглядеть нормально.

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

Что дают cache tags

Cache tags — это метки, прикрепленные к кэшированным ответам. Они позволяют вашему приложению заранее сказать Cloudflare, к чему относится ответ, прежде чем Cloudflare сохранит его на edge.

Это небольшое изменение дает гораздо лучший контроль над инвалидацией. Вместо того чтобы очищать всю зону, можно удалить только те страницы из кэша, у которых общий тег. Один клиент получает свежие данные, а у всех остальных остается теплый кэш.

В SaaS-дашборде теги обычно повторяют структуру данных. Обзор биллинга для тенанта 42 может получать теги вроде tenant:42, page:billing и invoice:8841.

Это дает выбор. Если меняется один счет, можно очистить тег счета. Если для одного аккаунта меняется весь биллинговый раздел, можно очистить сразу теги тенанта и billing. Если обновление дизайна затрагивает все страницы биллинга, можно очистить только тип страницы и не трогать другие экраны.

Именно поэтому cache tags так хорошо работают в многопользовательском кэшировании. Вы перестаете воспринимать кэш как одну большую кучу. Вы группируете его так же, как группируете свои данные.

Обычно достаточно простой модели тегов:

• тег по тенанту для данных, привязанных к конкретному клиенту
• тег по области страницы, когда от одного источника зависят многие URL
• тег по объекту, когда одна запись может измениться сама по себе

При такой схеме тенанты, которых изменение не касается, сохраняют свои кэшированные страницы, поддержка получает меньше сообщений в духе «почему приложение сегодня тормозит?», а origin избегает резкого всплеска запросов.

Выбирайте теги, которые соответствуют вашим данным

Сложность не в purge. Сложность в том, как понятно назвать вещи.

Начните с тенанта. Формат вроде tenant:123 легко искать, легко логировать и трудно перепутать. Если клиент 123 говорит, что на его дашборде все еще старые числа, один такой тег сразу дает четкую цель.

Затем добавьте теги для данных, которые показаны на странице. Биллинговый раздел может использовать invoice:9842, report:monthly-revenue или settings:billing. Так у вас появляются два полезных уровня: все для одного тенанта или только один изменившийся объект.

Обычно нужны оба.

Теги тенанта отвечают на вопрос: «очистить все кэшированные представления для этого клиента».

Объектные теги отвечают на вопрос: «очистить только страницы, связанные с этой записью».

Часто используется такой шаблон:

• tenant:123 — для контента, привязанного к одному аккаунту
• invoice:9842 — для страницы счета или любого другого представления, построенного на этом счете
• report:q2-mrr — для сгенерированного отчета
• settings:billing — для страниц или панелей настроек биллинга

Делайте имена короткими и скучными. Это комплимент.

Если одна команда пишет tenant:123, а другая — customer-123, purge начнут промахиваться мимо страниц, и никому не понравится выяснять почему. Выберите один формат, задокументируйте его и придерживайтесь его. То же правило относится и к объектным тегам. Используйте либо единственное число, либо множественное, но не оба варианта сразу. Решите, будут ли ID числовыми, slug-based или UUID-based. Небольшой дрейф в именах быстро превращает инвалидацию кэша в угадайку.

Полезно также определить владельца. Должно быть понятно, кто ставит каждый тег и когда. Рендерер дашборда может прикреплять tenant:123 ко всем кэшированным ответам, а сервис биллинга добавляет invoice-теги на страницах счетов. Когда заканчивается job по отчету, именно она должна запускать purge по тегу отчета.

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

Решите, что вообще не должно попадать в кэш

Некоторые ответы вообще не должны жить на edge. Если число на экране может измениться за секунды, кэш принесет больше вреда, чем пользы.

Пользователь, который только что оплатил счет, не должен обновить страницу и снова видеть старый баланс. Текущие балансы, счетчики использования, лимиты мест, одноразовые ссылки входа, токены сброса пароля и короткоживущие signed URLs должны приходить прямо с origin. То же относится ко всему, что связано с активной сессией конкретного человека.

Кэшировать имеет смысл спокойную часть страницы. Каркас дашборда часто остается одинаковым часами. Логотипы, CSS, JavaScript-бандлы, иконки и справочный текст — это хорошие и простые выигрыши. Некоторые отчеты тоже можно кэшировать, если пользователи согласны на небольшую задержку. Сводка продаж, обновляющаяся каждые 10 минут, обычно допустима. Баланс аккаунта — нет.

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

Хорошо работает простое правило:

• кэшируйте статические ресурсы и общие файлы разметки
• кэшируйте отчеты только тогда, когда допустима небольшая задержка
• обходите кэш для балансов, токенов и ответов, завязанных на сессию
• считайте данные API для вошедших пользователей приватными, если не доказали обратное

Для публичных и авторизованных данных нужна жесткая граница. Публичные страницы статуса, документация или страницы с ценами могут спокойно жить в кэше по широким правилам. Пользовательские дашборды, настройки команды, детали биллинга и админские экраны требуют более точной настройки. Если два тенанта могут когда-либо увидеть разный результат по одному и тому же URL, не кэшируйте такой ответ, если только ваш cache key намеренно не включает tenant и user context.

Проверьте и неприятные сценарии. Страницы ошибок часто попадают в кэш случайно, и один сбой upstream потом превращается в долгий день для поддержки. Redirects тоже могут создать проблемы рядом с потоками входа и выхода из системы. Проверьте ответы 301, 302, 401, 403 и 500 и убедитесь, что они получают именно то поведение кэша, которое вам нужно.

Если неверный кэшированный ответ может запутать пользователя или показать не те данные даже на 30 секунд, обходите кэш.

Как по шагам очистить кэш одного тенанта

Очистка кэша одного тенанта работает только тогда, когда вы заранее решили, какие кэшированные элементы принадлежат этому тенанту. Цель проста: удалить устаревшие данные для одного аккаунта и не трогать остальных.

Начинайте с действия на запись, а не с уровня кэша. Если пользователь меняет тариф, обновляет название команды или редактирует проект, перечислите каждую страницу и каждый API-ответ, которые могут показать эти данные. Включите очевидную страницу, но не забудьте боковые панели, карточки-итоги, результаты поиска, экспорт и виджеты с недавней активностью. Большинство плохих purge случаются из-за того, что один маленький кэшированный ответ забыли.

Здравый поток выглядит так:

1. Дайте тенанту общий тег, например tenant:acme, и прикрепляйте его к каждой кэшированной странице и каждому API-ответу, где есть данные этого тенанта.
2. Добавляйте более узкие объектные теги для записей, которые появляются в нескольких местах, например invoice:8432 или project:991.
3. Возвращайте оба тега, если один экран смешивает данные тенанта и данные записи.
4. Сначала завершайте запись в базу, а потом отправляйте purge по тегу.
5. Каждый раз логируйте запрос на очистку.

Объектные теги помогают избежать широких purge в будущем. Один счет может отображаться на странице счета, в общей сумме на дашборде, в списке просрочек и в админском поиске. Если все эти ответы разделяют один и тот же объектный тег, один purge убирает устаревшие копии, не затрагивая другие данные того же тенанта.

Время имеет значение. Если очистить кэш до завершения записи, следующий запрос может снова наполнить кэш старыми данными. Лучший порядок простой: зафиксировать изменение, опубликовать нужные события, а потом очистить соответствующие теги.

Поддержке тоже нужен понятный след, когда клиент говорит: «Я это изменил, а дашборд все равно выглядел неправильно». Логируйте достаточно деталей, чтобы можно было отследить событие:

• ID тенанта
• теги, отправленные в purge
• пользователь или сервис, который его запустил
• время и результат от Cloudflare
• request ID или trace ID

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

Пример биллингового дашборда

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

Допустим, тенант 42 открывает счет и меняет его статус с «pending» на «paid». Одно это действие меняет не только страницу со счетом. Нужно обновить список счетов, возможно, изменятся итоги на дашборде, а страница экспорта не должна продолжать отдавать старую версию.

Четкий план тегов держит радиус поражения маленьким:

• список счетов для тенанта 42 получает tenant:42
• страница счета получает tenant:42 и invoice:9182
• экспорт этого счета получает tenant:42 и invoice:9182

Когда пользователь нажимает сохранить, приложение обновляет базу, а затем очищает теги, связанные с этим изменением. В этом случае очищаются tenant:42 и invoice:9182, а не весь кэш.

Так вы получаете именно то поведение, которое нужно. Следующий запрос для tenant 42 получает свежий контент для списка счетов, страницы деталей и экспорта. Cloudflare заново забирает только эти страницы. Все остальные продолжают получать кэшированные ответы.

Tenant 77 не важно, что tenant 42 оплатил счет. Их дашборд должен оставаться быстрым. Их отчеты должны оставаться теплыми. Полный purge просто выбрасывает это преимущество и добавляет нагрузку на origin без причины.

Это особенно важно в загруженных биллинговых системах. Если десятки тенантов обновляют счета каждую минуту и каждое изменение очищает весь edge, вы обмениваете маленькое обновление данных на волну медленных загрузок по всему продукту. Это плохая сделка.

Ошибки, из-за которых purge идет не туда

Большинство плохих purge возникают из-за обычных ошибок: слишком широкие имена, отправка purge не в тот момент или кэшированные ответы, о которых никто не вспомнил.

Самая простая ошибка — ленивое именование тегов. Если вы используете один и тот же тег для многих тенантов, одно действие клиента может стереть кэш у всех остальных. Тег вроде account:dashboard сначала выглядит аккуратно, а потом становится проблемой, когда им начинают пользоваться тысячи тенантов. Вкладывайте идентичность тенанта в тег, а общие теги оставляйте только для действительно общего контента.

Еще один частый промах прячется за страницей, а не на ней. Дашборд может выглядеть как один экран, но на самом деле он часто тянет данные из нескольких API-ответов. Если вы очистили HTML, но забыли кэшированный API-ответ для счетов, использования или уведомлений, страница после обновления покажет старые числа. Пользователи обвинят дашборд, хотя устаревшие данные пришли из эндпоинта, который вы забыли очистить.

Время запуска тоже создает тихие баги. Если приложение отправляет purge до того, как запись в базе зафиксирована, Cloudflare может снова забрать старую запись и закэшировать ее. Пользователь обновляет страницу, видит устаревшие данные и решает, что обновление провалилось. Сначала завершайте запись, потом очищайте кэш.

Персонализированные фрагменты требуют особой осторожности. Если вы кэшируете пользовательские части вроде статуса тарифа, недавней активности или предупреждений аккаунта под общим тегом тенанта, можно показать не ту версию не тому человеку. Не кладите такой контент в общий кэш или тэгируйте его на более узком уровне.

Фоновые задачи тоже ломают кэш чаще, чем ожидают команды. Ночная синхронизация, webhook-worker или пересчет биллинга могут изменить данные тенанта, не проходя через тот код, который обычно отправляет purge. База уже свежая, а кэш — нет. На каждом пути обновления должны действовать одинаковые правила purge, включая задачи, которые запускаются через несколько часов.

Перед запуском проверьте несколько скучных, но важных вещей:

• у каждого тенанта свой namespace тегов
• учтены все кэшированные API-ответы, которые питают страницу
• purge запускается только после завершения записи
• пользовательский контент не попадает в общие cache tags
• worker'ы, cron-задачи и webhook-handlers используют те же правила purge

Если purge кажется непредсказуемым, проследите одно обновление тенанта от записи до рендера. Обычно там находится один пропущенный тег или один purge, отправленный слишком рано.

Быстрые проверки перед запуском

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

Только измененный тенант должен потерять кэш и пересобрать страницу. У другого тенанта должны по-прежнему отдаваться теплые страницы. Если кэш пропадает у обоих, теги слишком широкие, и обычное обновление будет ощущаться как мини-авария.

Короткий тест ловит большую часть неправильных настроек:

• отредактируйте одну запись в тестовом тенанте и подтвердите, что страница обновилась только там
• откройте ту же страницу для другого тенанта и убедитесь, что там по-прежнему cache HIT
• наблюдайте за временем ответа во время purge и при первом обновлении после него
• проверьте error rate во время теста, даже если изменение кажется маленьким
• просмотрите лог purge и убедитесь, что там видно, какой тенант и какие теги были очищены

Смотрите не только на корректность, но и на поведение. Страница может показывать свежие данные, но оставаться слишком медленной, потому что purge удалил больше, чем вы ожидали. Если cache status для не связанных тенантов меняется с HIT на MISS, остановитесь и сузьте шаблон тегов до запуска.

Потом протестируйте шумный сценарий. Запустите массовый импорт для одного тенанта и посмотрите, что будет, когда сразу меняется много записей. Вам нужен короткий всплеск miss'ов только для этого тенанта, а затем быстрое возвращение к норме. Другие тенанты должны оставаться стабильными.

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

Поддержке тоже нужен базовый обзор последних событий purge. Они должны видеть ID тенанта, время, причину и источник запуска, не обращаясь к engineering за поиском в логах.

Что делать дальше

Начните с одной части продукта, где устаревшие данные бьют по доверию, но модель данных еще легко описать. Страница биллинга, график использования или экран настроек команды — лучший первый кандидат, чем весь дашборд целиком. Небольшой объем делает первый запуск скучным, а скучность — это именно то, что вам нужно, когда правила кэша могут затронуть каждого тенанта.

Запишите план тегов рядом с правилом кэша. Если ответ получает tenant:42 и area:billing, зафиксируйте это в том же месте, где живет само правило. Когда кто-то позже поменяет эндпоинт, он должен сразу увидеть контракт purge.

Для первого запуска держите все компактно:

• кэшируйте одну область дашборда с небольшим набором тегов
• запускайте purge из того события, которое действительно меняет данные
• отслеживайте ошибки purge, всплески cache miss и нагрузку на origin несколько дней
• оставьте ручной fallback, чтобы support или engineering могли очистить кэш одного тенанта, не затрагивая остальных

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

Если вам нужен второй взгляд на tenant cache design или на purge-flows, Oleg Sotnikov на oleg.is разбирает такую архитектуру как часть своей работы Fractional CTO и startup advisory. Это особенно полезно, когда кэш уже работает в продакшене, а команда хочет меньше сюрпризов, а не еще одну большую систему.