Pag-invalidate ng Cache sa Pag-develop ng Mobile: Mga Estratehiya at Mekanismo

Ano ang pag-invalidate ng cache?

Pag-invalidate ng cache — ang proseso ng pagkansela o pag-update ng mga naka-cache na record na hindi na tumutugma sa kasalukuyang estado ng pinagmulan ng data. Hindi tulad ng manu-manong paglilinis ng buong cache, ang pag-invalidate ay gumagana nang tumpak: tanging ang data na pinag-aalinlanganan ang pagiging bago.

Ang cache ay nag-iimbak ng mga kopya ng data para sa mabilis na pag-access. Sa paglipas ng panahon, ang orihinal na data sa database o server ay maaaring magbago — halimbawa, na-update ng user ang kanyang profile o may lumabas na bagong post sa feed. Kung hindi ma-invalidate ang cache, ang app ay magpapakita ng lumang impormasyon, na sa mga mobile app ay humahantong sa mga error sa transaksyon, maling pagpapakita, at pagkawala ng tiwala.

Ang pangunahing hamon ng anumang pag-invalidate — ang kilalang kasabihan “There are only two hard things in Computer Science: cache invalidation and naming things”. Ang pagiging kumplikado ay nakasalalay sa katotohanan na hindi alam ng cache kung kailan nagbago ang pinagmulan, kung hindi ito sasabihin nang malinaw.

Ayon kay Martin Kleppmann, may-akda ng aklat na „Designing Data-Intensive Applications” (O’Reilly, 2017), ang tamang pag-invalidate ay nangangailangan ng sentralisadong abiso ng mga pagbabago o mekanismo ng pagsusuri ng pagiging bago sa bawat pagbasa — isang kompromiso sa pagitan ng pagganap at konsistensiya.

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

Ang kodigong ito ay nagpapakita ng simpleng approach: ang record sa cache ay itinuturing na valid kung hindi pa nag-e-expire ang TTL at ang bersyon ay tumutugma sa kasalukuyang bersyon sa pinagmulan. Ang mekanismo ng bersyon — isa sa mga maaasahang paraan upang maiwasang magpakita ng lumang data.

Bakit kailangan ang pag-invalidate sa mga mobile app

Pagiging bago ng data — pangunahing pangangailangan para sa karamihan ng mga mobile app: social network, messenger, serbisyo sa bangko, platform ng e-commerce. Ang user na nakakakita ng maling balanse ng account o lumang mensahe ay nawawalan ng tiwala sa app.

Bukod sa karanasan ng user, nilulutas ng pag-invalidate ang problema ng pagtitipid sa trapiko at baterya. Sa halip na pana-panahong buong pag-reload ng data, ang mobile app ay maaaring mag-invalidate lamang ng mga nabagong record at i-load ang mga ito nang tumpak. Ayon sa Meta Engineering (2024), ang pagpapatupad ng incremental na pag-invalidate sa Facebook Lite ay nagbawas ng konsumo ng trapiko ng 35% nang walang pagkawala ng pagiging bago ng nilalaman.

Isa pang mahalagang aspeto — konsistensiya ng transaksyon. Sa mga app na may shopping cart o reservation, ang paggamit ng lumang cache ay maaaring humantong sa dobleng pagbabawas o salungatan ng data. Ang pag-invalidate pagkatapos ng kritikal na operasyon ay ginagarantiyang babasahin ng susunod na request ang sariwang data.

Mga pangunahing estratehiya sa pag-invalidate ng cache

TTL (Time-To-Live)

TTL — ang pinakasimpleng estratehiya, kung saan ang bawat record sa cache ay nakakakuha ng nakapirming habang-buhay. Pagkatapos mag-expire ng TTL, ang data ay itinuturing na luma at tinatanggal sa susunod na pagbasa. Ang TTL ay perpekto para sa data na ina-update ayon sa iskedyul — halimbawa, panahon o halaga ng palitan. Kahinaan: ang data ay maaaring hindi bago sa loob ng TTL interval.

Write-Through

Sa estratehiyang Write-Through, ang bawat pagbabago ng data ay dumadaan sa cache: ang pagsulat ay sabay na isinasagawa sa cache at sa pinagmulan. Ginagarantiyahan nito na ang cache ay laging naglalaman ng kasalukuyang bersyon. Kahinaan — tumataas ang latency ng pagsulat, dahil hindi nakumpleto ang operasyon hanggang sa kumpirmasyon mula sa pinagmulan. Ang Write-Through ay angkop para sa data na kritikal sa konsistensiya: balanse ng account, status ng order.

Write-Behind (Write-Back)

Write-Behind — asinkronong pagsulat: ang data ay agad na pumapasok sa cache, at sa pinagmulan ay isinusulat mamaya ng isang hiwalay na proseso. Ito ay nagbibigay ng mataas na pagganap sa pagsulat, ngunit nagdadala ng panganib ng pagkawala ng data kung magkaroon ng aberya bago ang pag-sync. Sa mga mobile app, ang Write-Behind ay kadalasang ginagamit para sa analytics, log, at hindi kritikal na pagkilos ng user.

Write-Invalidate

Write-Invalidate — sa halip na i-update ang cache kapag nagbago ang data, tinatanggal lang nito (ini-invalidate) ang kaukulang record. Ang susunod na pagbasa ay makakatuklas ng cache miss at maglo-load ng sariwang data mula sa pinagmulan. Ang estratehiyang ito ay simple sa implementasyon at gumagana nang maayos kapag ang mga request sa pagbasa ay mas marami kaysa sa pagsulat.

Ang pagpili ng estratehiya ay depende sa kung ano ang prayoridad para sa partikular na senaryo: bilis ng tugon, konsistensiya, o pagtitipid ng resource. Mga hybrid na approach — halimbawa, TTL na may Write-Invalidate kapag nakatanggap ng push notification — ay nagbibigay ng optimal na balanse.

Paano gumagana ang pag-invalidate sa iba't ibang antas ng cache

Cache ng HTTP — unang antas sa panig ng kliyente. Ang browser o mobile app ay nag-iimbak ng mga tugon ng server na may mga header na Cache-Control at ETag. Ang pag-invalidate ay nangyayari kapag nakatanggap ng tugon na 304 Not Modified o pagkatapos mag-expire ng max-age. Ang ETag ay nagpapahintulot sa kliyente na suriin ang pagiging bago ng resource nang hindi nilo-load ang buong tugon.

Cache ng app — ikalawang antas, pinamamahalaan ng code: in-memory cache (LRU, LruCache sa Android) o disk (SQLite, Room, Realm). Ang pag-invalidate dito ay kinokontrol ng developer. Ayon sa Android Developers (2025), ang tamang paggamit ng Room na may Flow at pag-invalidate sa pamamagitan ng trigger ay nagbabawas ng bilang ng UI redraw ng 40%.

Cache ng server — ikatlong antas: Redis, Memcached, CDN. Sa antas na ito, ang pag-invalidate ay ginagawa sa pamamagitan ng TTL, utos na DEL/PURGE, o message broker (RabbitMQ, Kafka). Pag-invalidate ng CDN — isang hiwalay na gawain: dahil sa distributed na kalikasan ng CDN, ang utos sa paglilinis ay maaaring kumalat nang ilang minuto. Ayon sa Cloudflare (2024), ang pag-invalidate sa pamamagitan ng Purge by URL ay tumatagal ng average na 5–15 segundo para sa pandaigdigang pagkalat.

Para sa koordinasyon ng pag-invalidate sa lahat ng antas, ginagamit ang sentralisadong serbisyo ng cache o event broker. Kapag nagbago ang data, nag-publish ang pinagmulan ng isang event, at bawat antas ay tumatanggap ng utos na i-invalidate ang mga partikular na key. Pinipigilan nito ang sitwasyon kung saan na-update na ng isang antas ang data habang ang isa ay patuloy na nagbibigay ng lumang bersyon.

Mga karaniwang pagkakamali sa pag-invalidate ng cache

Masyadong mahabang TTL — pinakakaraniwang pagkakamali. Itinatakda ng mga developer ang TTL “na may reserba”, na humahantong sa mga user na nakakakita ng lumang data nang ilang oras o araw. Solusyon: magsimula sa maikling TTL (1–5 minuto) at dagdagan lamang ito pagkatapos sukatin ang aktwal na pangangailangan.

Pag-invalidate ng buong cache sa isang pagbabago — tipikal na problema sa arkitekturang microservice. Isang user ang nag-update ng avatar, at ang cache ay ini-invalidate para sa lahat. Sa malaking bilang ng mga user, ito ay nagdudulot ng epekto ng Cache Stampede — isang avalanche ng mga request sa pinagmulan. Solusyon: i-invalidate lamang ang key ng partikular na user, hindi ang buong cache.

Kawalan ng pag-invalidate sa mga error sa pagsulat — kung nabigo ang pagsulat sa pinagmulan at na-update na ang cache, ang app ay napupunta sa hindi konsistent na estado. Solusyon: dalawang-phase na pag-invalidate — linisin muna ang cache, pagkatapos ay sumulat sa pinagmulan, at i-undo ang pag-invalidate kung may error.

Pagbalewala sa distributed na kalikasan — sa kapaligiran ng cluster, ang pag-invalidate sa isang node ay hindi nangangahulugang nakatanggap ng utos ang ibang mga node. Kung walang event broker, ang ilang server ay patuloy na magbibigay ng lumang data. Redis Pub/Sub o Apache Kafka ay nilulutas ang problemang ito sa pamamagitan ng pagpapakalat ng mga event ng pag-invalidate.

Paano pumili ng estratehiya sa pag-invalidate

Tukuyin ang mga pangangailangan sa pagiging bago — gaano ba kritikal na ang data ay sariwang “ngayon na”. Para sa news feed, ang pagkaantala ng 1–2 minuto ay katanggap-tanggap (TTL). Para sa balanse ng account — hindi katanggap-tanggap ang pagkaantala (Write-Through).

Tayahin ang dalas ng mga pagbabago — ang data na ina-update isang beses sa isang araw (katalogo ng produkto, direktoryo ng lungsod) ay mahusay na gumagana sa TTL. Ang data na nagbabago nang sampu-sampung beses bawat segundo (online status, halaga ng palitan) ay nangangailangan ng push invalidation sa pamamagitan ng WebSocket o Firebase Cloud Messaging.

Isaalang-alang ang gastos ng pagbasa ng pinagmulan — kung ang pinagmulan ay isang mamahaling SQL query sa 10 talahanayan o external na API na may mga limitasyon, mas mainam na gumamit ng agresibong caching na may mahabang TTL, ngunit kompensahin ang lumang data sa pamamagitan ng push invalidation. Kung mura ang pagbasa (in-memory lookup), maaaring gumamit ng maikling TTL at Write-Invalidate.

Ayon sa Google I/O (2025), ang tipikal na pattern para sa mobile app — Stale-While-Revalidate: agad na nakikita ng user ang naka-cache na data, at ang app sa background ay sumusuri ng pagiging bago at ina-update ang mga ito. Pinagsasama nito ang bilis ng tugon at pagiging bago nang walang kompromiso. Ang HTTP header na Cache-Control na may directive na stale-while-revalidate ay sinusuportahan mula sa Android 10 at iOS 13.