Инвалидација кеша у мобилном развоју: стратегије и механизми

Шта је инвалидација кеша?

Инвалидација кеша — процес поништавања или ажурирања кешираних записа који више не одговарају тренутном стању извора података. За разлику од ручног чишћења целог кеша, инвалидација ради тачкасто: само они подаци чија је актуелност упитна.

Кеш чува копије података за брзи приступ. Временом се оригинални подаци у бази или на серверу могу променити — на пример, корисник је ажурирао профил или се појавила нова објава у фиду. Ако се кеш не инвалидира, апликација ће приказати застареле информације, што у мобилним апликацијама доводи до грешака у трансакцијама, нетачног приказа и губитка поверења.

Главна потешкоћа сваке инвалидације — позната изрека „There are only two hard things in Computer Science: cache invalidation and naming things“. Сложеност је у томе што кеш не зна када се извор променио, ако му се то експлицитно не саопшти.

Према подацима Мартина Клепмана, аутора књиге „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 инвалидацију путем WebSocket-а или Firebase Cloud Messaging-а.

Узмите у обзир цену читања извора — ако је извор скупи SQL упит на 10 табела или спољни API са ограничењима, боље је користити агресивно кеширање са дугим TTL-ом, али компензовати застареле податке push инвалидацијом. Ако је читање јефтино (in-memory lookup), може се користити кратки TTL и Write-Invalidate.

Према подацима Google I/O (2025), типичан образац за мобилну апликацију — Stale-While-Revalidate: корисник тренутно види кеширане податке, а апликација у позадини проверава њихову актуелност и ажурира их. Ово комбинује брзину одговора и актуелност без компромиса. HTTP заглавље Cache-Control са директивом stale-while-revalidate подржано је од Android 10 и iOS 13.