Кеші

Коротко: Проміжне сховище, що зберігає вже отримані дані для швидшого повторного доступу.

Докладніше: Кеші існують на багатьох рівнях — у браузері (HTML/CSS/JS/зображення), на DNS-резолверах (відповіді до спливу TTL), у CDN або в підключенні застосунку до бази даних. Мета завжди одна: рідше звертатися до повільніших першоджерел (мережа, база даних).

Подробиці

Корисна картина: кожен шар кешу — компроміс між швидкістю та свіжістю. Чим ближче кеш до користувача, тим він швидший, але тим вищий ризик видати застарілі дані.

• Кеш браузера: зберігає статичні ресурси (зображення, CSS, JS) локально на пристрої користувача — найшвидший шар, але окремий для кожного пристрою.
• Кеш CDN: глобально розподілена мережа серверів, що тримає вміст географічно близько до користувача — наприклад, edge-мережа Vercel автоматично кешує статичні сторінки Emzett.
• Кеш DNS: резолвери запам’ятовують відповіді до спливу TTL, щоб не проходити весь ланцюжок DNS заново за кожного запиту.
• Кеш застосунку/бази даних: наприклад, кеші Redis для дорогих запитів до бази даних.

Кожен із цих кешів може видавати застарілі («stale») дані, якщо першоджерело змінюється до оновлення кешу, — тому фундаментальна проблема кешування не в самому кешуванні, а в своєчасній і правильній інвалідації. Для цього є дві базові стратегії: спливання за часом (кеш автоматично відкидає запис після фіксованого TTL, незалежно від того, чи змінилися дані насправді) і явна інвалідація (застосунок активно повідомляє кешу «цей запис тепер недійсний», наприклад одразу після оновлення бази даних).

Узгодженість кешу як справжня проблема

За кількох шарів кешу одночасно (браузер, CDN, застосунок) один і той самий запит може давати відповіді різної актуальності залежно від шару — користувач, наприклад, усе ще бачить у кеші браузера стару ціну товару, а CDN уже давно віддає нову. Саме це регулюють заголовки HTTP, такі як Cache-Control та ETag:

Cache-Control: max-age=3600, must-revalidate
ETag: "a1b2c3d4"

max-age вказує, як довго клієнт може використовувати відповідь без нового запиту; must-revalidate потім примушує до перевірки на сервері (замість того щоб просто далі використовувати застарілу версію); ETag — відбиток вмісту, що дає змогу серверу під час такої перевірки ефективно з’ясувати, чи щось змінилося насправді, не передаючи заново всю відповідь (відповідь 304 Not Modified, якщо ні).

Ділянкою, яку в Emzett навмисно НЕ кешують, є, наприклад, стан кошика — тут навіть кеш із часом життя в кілька секунд був би реальним ризиком показати неправильні залишки.

Див. також: Кешування (caching), TTL