Invalidace mezipaměti v mobilním vývoji: strategie a mechanismy

Co je invalidace mezipaměti?

Invalidace mezipaměti — proces zrušení nebo aktualizace uložených záznamů, které již neodpovídají aktuálnímu stavu zdroje dat. Na rozdíl od ručního čištění celé mezipaměti funguje invalidace cíleně: pouze ta data, jejichž aktuálnost je zpochybněna.

Mezipaměť ukládá kopie dat pro rychlý přístup. Časem se původní data v databázi nebo na serveru mohou změnit — například uživatel aktualizoval profil nebo se objevil nový příspěvek v kanálu. Pokud není mezipaměť invalidována, aplikace zobrazí zastaralé informace, což v mobilních aplikacích vede k chybám transakcí, nesprávnému zobrazení a ztrátě důvěry.

Hlavní obtížnost každé invalidace — známé rčení „There are only two hard things in Computer Science: cache invalidation and naming things”. Složitost spočívá v tom, že mezipaměť neví, kdy se zdroj změnil, pokud jí to není výslovně sděleno.

Podle údajů Martina Kleppmanna, autora knihy „Designing Data-Intensive Applications” (O’Reilly, 2017), správná invalidace vyžaduje buď centralizované oznamování změn, nebo mechanismus kontroly aktuálnosti při každém čtení — kompromis mezi výkonem a konzistencí.

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

Tento kód ukazuje jednoduchý přístup: záznam v mezipaměti je považován za platný, pokud nevypršel TTL a verze se shoduje s aktuální verzí ve zdroji. Mechanismus verzování — jeden ze spolehlivých způsobů, jak se vyhnout zobrazování zastaralých dat.

Proč je invalidace v mobilních aplikacích potřebná

Aktuálnost dat — klíčový požadavek pro většinu mobilních aplikací: sociální sítě, messengery, bankovní služby, e-commerce platformy. Uživatel, který vidí nesprávný zůstatek účtu nebo staré zprávy, ztrácí důvěru v aplikaci.

Kromě uživatelského zážitku řeší invalidace problém úspory provozu a baterie. Místo periodického úplného znovunačtení dat může mobilní aplikace invalidovat pouze změněné záznamy a načíst je cíleně. Podle údajů Meta Engineering (2024) zavedení inkrementální invalidace ve Facebook Lite snížilo spotřebu provozu o 35% bez ztráty aktuálnosti obsahu.

Další důležitý aspekt — konzistence transakcí. V aplikacích s nákupním košíkem nebo rezervacemi může použití zastaralé mezipaměti vést k dvojímu zatížení nebo konfliktům dat. Invalidace po kritických operacích zaručuje, že další požadavek přečte čerstvá data.

Hlavní strategie invalidace mezipaměti

TTL (Time-To-Live)

TTL — nejjednodušší strategie, při které každý záznam v mezipaměti získá pevnou dobu životnosti. Po vypršení TTL jsou data považována za zastaralá a při příštím čtení odstraněna. TTL je ideální pro data, která se aktualizují podle plánu — například počasí nebo směnné kurzy. Nevýhoda: data mohou být neaktuální v rámci TTL intervalu.

Write-Through

Při strategii Write-Through každá změna dat prochází mezipamětí: zápis se provádí současně do mezipaměti i do zdroje. To zaručuje, že mezipaměť vždy obsahuje aktuální verzi. Nevýhoda — zpoždění zápisu roste, protože operace není dokončena do potvrzení ze zdroje. Write-Through je vhodný pro data kritická pro konzistenci: zůstatek účtu, stav objednávky.

Write-Behind (Write-Back)

Write-Behind — asynchronní zápis: data se okamžitě dostanou do mezipaměti a do zdroje jsou zapsána později samostatným procesem. To poskytuje vysoký výkon zápisu, ale nese riziko ztráty dat při selhání před synchronizací. V mobilních aplikacích se Write-Behind často používá pro analytiku, protokoly a nekritické uživatelské akce.

Write-Invalidate

Write-Invalidate — místo aktualizace mezipaměti při změně dat jednoduše odstraní (invaliduje) příslušný záznam. Příští čtení detekuje selhání mezipaměti a načte čerstvá data ze zdroje. Tato strategie je jednoduchá na implementaci a dobře funguje, když je požadavků na čtení výrazně více než na zápis.

Výběr strategie závisí na tom, co je pro konkrétní scénář prioritou: rychlost odezvy, konzistence nebo úspora zdrojů. Hybridní přístupy — například TTL s Write-Invalidate při přijetí push oznámení — poskytují optimální rovnováhu.

Jak funguje invalidace na různých úrovních mezipaměti

Mezipaměť HTTP — první úroveň na straně klienta. Prohlížeč nebo mobilní aplikace ukládá odpovědi serveru s hlavičkami Cache-Control a ETag. K invalidaci dochází při obdržení odpovědi 304 Not Modified nebo po vypršení max-age. ETag umožňuje klientovi zkontrolovat aktuálnost zdroje bez načítání úplné odpovědi.

Mezipaměť aplikace — druhá úroveň, řízená kódem: mezipaměti v paměti (LRU, LruCache v Android) nebo diskové (SQLite, Room, Realm). Invalidaci zde řídí vývojář. Podle údajů Android Developers (2025) správné použití Room s Flow a invalidací pomocí triggerů snižuje počet překreslení UI o 40%.

Mezipaměť serveru — třetí úroveň: Redis, Memcached, CDN. Na této úrovni se invalidace provádí pomocí TTL, příkazů DEL/PURGE nebo brokerů zpráv (RabbitMQ, Kafka). Invalidace CDN — samostatný úkol: kvůli distribuované povaze CDN se může příkaz k vyčištění šířit minuty. Podle údajů Cloudflare (2024) trvá invalidace pomocí Purge by URL v průměru 5–15 sekund pro globální rozšíření.

Pro koordinaci invalidace na všech úrovních se používá centralizovaná služba mezipaměti nebo broker událostí. Při změně dat zdroj zveřejní událost a každá úroveň obdrží příkaz k invalidaci konkrétních klíčů. To zabraňuje situaci, kdy jedna úroveň již data aktualizovala, zatímco jiná nadále poskytuje zastaralou verzi.

Typické chyby při invalidaci mezipaměti

Příliš dlouhý TTL — nejčastější chyba. Vývojáři nastaví TTL “s rezervou”, což vede k tomu, že uživatelé vidí zastaralá data hodiny nebo dny. Řešení: začněte s krátkým TTL (1–5 minut) a zvyšujte jej až po změření skutečné potřeby.

Invalidace celé mezipaměti při jedné změně — typický problém v mikroslužbové architektuře. Jeden uživatel aktualizoval avatar a mezipaměť je invalidována pro všechny. Při velkém počtu uživatelů to způsobuje efekt Cache Stampede — lavinu požadavků na zdroj. Řešení: invalidujte pouze klíč konkrétního uživatele, ne celou mezipaměť.

Chybějící invalidace při chybách zápisu — pokud zápis do zdroje selže a mezipaměť je již aktualizována, aplikace se ocitne v nekonzistentním stavu. Řešení: dvoufázová invalidace — nejprve vyčistěte mezipaměť, poté zapište do zdroje a při chybě invalidaci vraťte.

Ignorování distribuované povahy — v clusterovém prostředí invalidace na jednom uzlu neznamená, že ostatní uzly obdržely příkaz. Bez brokera událostí bude část serverů nadále poskytovat zastaralá data. Redis Pub/Sub nebo Apache Kafka řeší tento problém šířením událostí invalidace.

Jak vybrat strategii invalidace

Určete požadavky na aktuálnost — jak kritické je, aby data byla čerstvá “teď hned”. Pro zpravodajský kanál je zpoždění 1–2 minut přijatelné (TTL). Pro zůstatek účtu je zpoždění nepřijatelné (Write-Through).

Vyhodnoťte frekvenci změn — data, která se aktualizují jednou denně (katalog produktů, průvodce městy), fungují skvěle s TTL. Data měnící se desítkykrát za sekundu (online statusy, kurzy měn) vyžadují push invalidaci prostřednictvím WebSocketu nebo Firebase Cloud Messaging.

Zvažte náklady na čtení zdroje — pokud je zdroj drahý SQL dotaz na 10 tabulek nebo externí API s omezeními, je lepší použít agresivní ukládání do mezipaměti s dlouhým TTL, ale kompenzovat zastaralá data push invalidací. Pokud je čtení levné (in-memory lookup), lze použít krátký TTL a Write-Invalidate.

Podle údajů Google I/O (2025) je typickým vzorem pro mobilní aplikaci — Stale-While-Revalidate: uživatel okamžitě vidí data z mezipaměti a aplikace na pozadí kontroluje jejich aktuálnost a aktualizuje je. To kombinuje rychlost odezvy a aktuálnost bez kompromisů. HTTP hlavička Cache-Control s direktivou stale-while-revalidate je podporována od Androidu 10 a iOS 13.