Безпечне кешування сайту перед кампанією

Навіщо

Сервер уже стабільний. Кеш — це додатковий запас на піки реклами.

Ми вже виправили памʼять і прискорили базу — сервер витримує навантаження. Кешування дозволяє не рахувати одне й те саме тисячі разів, а віддавати готову відповідь. У піки реклами це суттєво розвантажує сервер. Але саме кеш колись спричинив два інциденти — тому вмикаємо його обережно й тільки за вашим погодженням.

⚡

Що дає кеш

Сервер на короткий час запам'ятовує відповідь і віддає її всім, хто питає те саме — замість рахувати щоразу заново.

📈

Чому це важливо для кампанії

Реклама жене багато однакових запитів на каталог. Кеш «склеює» їх в один — сервер тримає пік спокійно.

🛡️

Чому обережно

Неправильний кеш колись показав застарілу бронь і дані іншого користувача. Ця пропозиція побудована так, щоб цього не сталося.

Головне про безпеку

Дві минулі проблеми — і як ця пропозиція їх закриває

Ми точно знаємо, чому тоді сталися збої. Це різні причини — і в новому плані кожна закрита окремо.

Було · ризик приватності

Користувач бачив чужий кабінет

Спільний кеш зберіг сторінку залогіненого користувача й віддав її іншому — бо не враховував, що людина авторизована.

Стане · закрито правилом

Будь-який авторизований запит іде повз кеш — у живу систему. Як тільки людина увійшла у свій акаунт — її відповідь ніколи не потрапляє у спільний кеш. Витік чужих даних стає технічно неможливим. Це ж правило коректно обслуговує авторизованих користувачів, які бачать додаткові позиції каталогу.

Було · ризик актуальності

Застаріла бронь квартири

Кеш тримав сторінку 10 хвилин, а статус квартири (бронь із Salesforce) уже змінився — і користувач бачив старе.

Стане · закрито свіжістю

Дуже коротке вікно кешу (секунди) + миттєве скидання при зміні броні. Сама дія бронювання завжди йде в живу систему. Кеш впливає лише на те, як швидко статус побачать ЧУЖІ браузери — це секунди, а не хвилини.

Варіанти на вибір

Три варіанти — оберіть рівень, що вам комфортний

Кожен наступний дає більше розвантаження, але потребує більше налаштування й тестування. Ми рекомендуємо почати з варіанта A.

Рекомендуємо

Варіант A

Статика + мікрокеш 1–5с

Кешуємо незмінну статику (картинки, скрипти) та публічний каталог на кілька секунд.

Сильний захист від піків реклами
Ризик обох інцидентів — практично нульовий
Швидко вмикається й миттєво відкочується
Несвіжість — лише 1–5 секунд
Розвантаження часткове (динаміка все одно рахується)

Варіант B

A + кеш каталогу 30–60с

Додатково кешуємо публічний каталог довше, зі скиданням кеша при кожній зміні броні.

Максимальне розвантаження сервера
Свіжість тримає миттєве скидання при бронюванні
Складніше: треба вчепити «скидання» у синк Salesforce та угоди
Потребує більшого тестування перед увімкненням

Варіант C

Залишити як є

Кеш динаміки не вмикаємо. Сервер обслуговує кожен запит наживо.

Нуль додаткового ризику
Нічого не змінюємо
Під великим піком сервер працює на межі, менший запас
Не використовуємо можливість здешевити навантаження

Окремо зазначимо: «важку» техніку Cloudflare (Cache Reserve, Tiered Cache), яка свого часу й розтягнула проблему надовго, для динамічних сторінок вмикати не будемо — лише для незмінної статики.

Запобіжники

Що гарантує безпеку — у будь-якому варіанті

✓

Авторизовані — завжди повз кеш. Кабінет і бронювання — лише жива система. Чужі дані не можуть потрапити у спільний кеш.

✓

Бронювання — завжди наживо. Сама дія ніколи не кешується; кеш впливає лише на швидкість показу статусу іншим — це секунди.

✓

Кешуємо лише явно дозволене. За замовчуванням — без кешу; вмикаємо точково для безпечних публічних сторінок.

✓

Поетапно й оборотно. Вмикаємо в непікові години, з моніторингом і миттєвим відкотом одним рухом.

Як перевіримо перед увімкненням

Жодних змін наосліп — спершу тест

У нас уже є власний інструмент навантажувального тестування. Перед увімкненням на проді проходимо три етапи.

ЕТАП 1

Статика на CDN

Вмикаємо кеш незмінних файлів (безпечно) і вимірюємо, скільки трафіку це знімає з сервера.

ЕТАП 2

Тест мікрокешу

Вмикаємо мікрокеш обмежено, проганяємо навантажувальний тест і перевіряємо за чек-листом: кабінет і бронь — свіжі та ізольовані.

ЕТАП 3

Прод + моніторинг

Вмикаємо на проді в непікові години, спостерігаємо за метриками й тримаємо миттєвий відкат напоготові.

Критерії успіху: пропускна здатність зростає, навантаження на сервер падає, і нуль інцидентів зі свіжістю чи приватністю на тесті.