Інвалідація кешу в мобільній розробці: стратегії та механізми

Що таке інвалідація кешу?

Інвалідація кешу — це процес анулювання або оновлення кешованих записів, які перестали відповідати актуальному стану джерела даних. На відміну від ручного очищення всього кешу, інвалідація працює точково: лише ті дані, чия актуальність під питанням.

Кеш зберігає копії даних для швидкого доступу. З часом оригінальні дані в базі або на сервері можуть змінитися — наприклад, користувач оновив профіль або з'явився новий пост у стрічці. Якщо кеш не інвалідувати, додаток покаже застарілу інформацію, що в мобільних додатках веде до помилок транзакцій, некоректного відображення та втрати довіри.

Головна складність будь-якої інвалідації — відома приказка «There are only two hard things in Computer Science: cache invalidation and naming things». Складність у тому, що кеш не знає, коли джерело змінилося, якщо йому про це не повідомити явно.

За даними Martin Kleppmann, автора книги «Designing Data-Intensive Applications» (O'Reilly, 2017), коректна інвалідація вимагає або централізованого сповіщення про зміни, або механізму перевірки актуальності при кожному читанні — компромісу між продуктивністю та консистентністю.

data class CacheEntryT(
    val data: T,
    val expiresAt: Long,
    val version: Int = 0
)

fun CacheT.isValid(key: String): Boolean =
    get(key)?.let { it.expiresAt > currentTimeMillis() && it.version == currentVersion(key) } ?: false

Цей код показує простий підхід: запис у кеші вважається валідним, якщо не минув TTL і версія збігається з актуальною в джерелі. Механізм версіонування — один із надійних способів уникнути показу застарілих даних.

Навіщо потрібна інвалідація в мобільних додатках

Актуальність даних — ключова вимога для більшості мобільних додатків: соціальних мереж, месенджерів, банківських сервісів, e-commerce платформ. Користувач, який побачив невірний баланс рахунку або старі повідомлення, втрачає довіру до додатку.

Окрім користувацького досвіду, інвалідація вирішує задачу економії трафіку та батареї. Замість періодичного повного перезавантаження даних, мобільний додаток може інвалідувати лише змінені записи та завантажити їх точково. За даними Meta Engineering (2024), впровадження інкрементальної інвалідації в Facebook Lite скоротило витрати трафіку на 35% без втрати актуальності контенту.

Ще один важливий аспект — консистентність транзакцій. У додатках із кошиком покупок або бронюванням використання застарілого кешу може призвести до подвійних списань або конфліктів даних. Інвалідація після критичних операцій гарантує, що наступний запит прочитає свіжі дані.

Основні стратегії інвалідації кешу

TTL (Time-To-Live)

TTL — найпростіша стратегія, при якій кожен запис у кеші отримує фіксований час життя. Після закінчення TTL дані вважаються застарілими та видаляються при наступному читанні. TTL ідеальний для даних, які оновлюються за розкладом — наприклад, погода або курс валют. Мінус: дані можуть бути неактуальними всередині TTL-інтервалу.

Write-Through

При стратегії Write-Through кожна зміна даних проходить через кеш: запис одночасно виконується і в кеш, і в джерело. Це гарантує, що кеш завжди містить актуальну версію. Недолік — затримка на запис зростає, оскільки операція не завершується до підтвердження від джерела. Write-Through підходить для критичних до консистентності даних: баланс рахунку, статус замовлення.

Write-Behind (Write-Back)

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

Write-Invalidate

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

Вибір стратегії залежить від того, що пріоритетніше для конкретного сценарію: швидкість відповіді, консистентність чи економія ресурсів. Гібридні підходи — наприклад, TTL з Write-Invalidate при отриманні push-повідомлення — дають оптимальний баланс.

Як працює інвалідація на різних рівнях кешу

Кеш HTTP — перший рівень на стороні клієнта. Браузер або мобільний додаток зберігає відповіді сервера з заголовками Cache-Control та ETag. Інвалідація відбувається при отриманні відповіді 304 Not Modified або після закінчення max-age. ETag дозволяє клієнту перевірити актуальність ресурсу без завантаження повної відповіді.

Кеш додатку — другий рівень, керований кодом: in-memory кеші (LRU, LruCache в Android) або дискові (SQLite, Room, Realm). Інвалідацію тут контролює розробник. За даними Android Developers (2025), правильне використання Room з Flow та інвалідацією через тригери зменшує кількість перемальовувань UI на 40%.

Кеш сервера — третій рівень: Redis, Memcached, CDN. На цьому рівні інвалідація виконується через TTL, команди DEL/PURGE або брокери повідомлень (RabbitMQ, Kafka). CDN-інвалідація — окреме завдання: через розподілену природу CDN команда очищення може поширюватися хвилини. За даними Cloudflare (2024), інвалідація через Purge by URL займає в середньому 5–15 секунд для глобального поширення.

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

Типові помилки при інвалідації кешу

Занадто довгий TTL — найчастіша помилка. Розробники задають TTL «із запасом», що призводить до того, що користувачі бачать застарілі дані години або дні. Рішення: починати з короткого TTL (1–5 хвилин) і збільшувати його тільки після заміру реальної потреби.

Інвалідація всього кешу при одній зміні — типова проблема в мікросервісній архітектурі. Один користувач оновив аватар, а кеш інвалідується для всіх. При великій кількості користувачів це викликає ефект Cache Stampede — лавину запитів до джерела. Рішення: інвалідувати тільки ключ конкретного користувача, а не спільний кеш.

Відсутність інвалідації при помилках запису — якщо запис у джерело провалився, а кеш вже оновлено, додаток опиняється в неконсистентному стані. Рішення: двофазна інвалідація — спочатку очищати кеш, потім писати в джерело, і відкочувати інвалідацію при помилці.

Ігнорування розподіленої природи — у кластерному середовищі інвалідація на одній ноді не означає, що інші ноди отримали команду. Без брокера подій частина серверів продовжить віддавати застарілі дані. Redis Pub/Sub або Apache Kafka вирішують цю проблему через розсилку подій інвалідації.

Як вибрати стратегію інвалідації

Визначте вимоги до актуальності — наскільки критично, щоб дані були свіжими «прямо зараз». Для стрічки новин допустиме запізнення в 1–2 хвилини (TTL). Для балансу рахунку — затримка неприпустима (Write-Through).

Оцініть частоту змін — дані, які оновлюються раз на добу (каталог товарів, довідник міст), чудово працюють з TTL. Дані, що змінюються десятки разів на секунду (онлайн-статуси, курс валют), вимагають push-інвалідації через вебсокети або Firebase Cloud Messaging.

Врахуйте вартість читання джерела — якщо джерело — це дорогий SQL-запит на 10 таблиць або зовнішнє API з лімітами, краще використовувати агресивне кешування з довгим TTL, але компенсувати stale-дані push-інвалідацією. Якщо читання дешеве (in-memory lookup), можна використовувати короткий TTL та Write-Invalidate.

За даними Google I/O (2025), типовий шаблон для мобільного додатку — Stale-While-Revalidate: користувач миттєво бачить закешовані дані, а додаток у фоні перевіряє їх актуальність та оновлює. Це поєднує швидкість відповіді та актуальність без компромісів. HTTP-заголовок Cache-Control з директивою stale-while-revalidate підтримується починаючи з Android 10 та iOS 13.