Mobile Cache Strategy: Mermaid Flowchart Diagram

About Source

A mobile cache strategy defines the rules by which an app decides whether to serve data from a local store, fetch fresh data from the network, or do both simultaneously — balancing perceived performance, data freshness, and bandwidth consumption.

Mobile apps commonly implement one of three strategies, each appropriate for different data types:

Cache-first serves the cached value immediately if it exists, regardless of staleness, and only reaches the network if the cache is empty. This is ideal for truly static assets — app configuration, feature flags fetched at startup, country or category lists that rarely change. The risk is serving stale data for longer than intended.

Network-first always attempts a network request, falls back to the cache only on failure. This is appropriate for data where freshness is critical — user account details, order status, real-time inventory. The downside is that every request incurs network latency, and on slow connections the UI stalls.

Stale-while-revalidate serves the cached value immediately (fast perceived response) and simultaneously fires a network request in the background. When the fresh response arrives, the cache is updated and the UI is updated if the data changed. This is the most commonly used strategy for social feeds, dashboards, and content listings where users tolerate briefly stale data but expect fast loads.

Cache entries carry metadata: a TTL (time-to-live), a timestamp, and an ETag or content hash for conditional requests. When a TTL expires, the entry is considered stale but not deleted — it remains available as the fallback while a revalidation request is in flight. Periodic cache eviction removes entries that exceed a maximum age or when storage pressure requires it.

For how caching fits into the full API request lifecycle, see Mobile API Sync. For caching during offline periods, see Offline Sync Workflow.

Frequently asked questions

A mobile cache strategy is a set of rules that determines whether an app serves data from a local store, fetches it from the network, or does both simultaneously — balancing perceived performance, data freshness, and bandwidth usage for a specific data type.

The app immediately returns the cached value so the UI renders without waiting for a network round-trip, then fires a background network request. When the fresh response arrives, the cache is updated and the UI re-renders only if the data changed — giving users fast loads with eventually-consistent freshness.

Use cache-first for rarely-changing static data like feature flags or country lists. Use network-first when data freshness is critical and latency is acceptable, such as live order status. Use stale-while-revalidate for social feeds and dashboards where users tolerate briefly stale content but expect instant perceived response.

Setting TTLs too long for volatile data causes users to see stale prices or statuses. Failing to scope cache keys by user ID leaks one user's data to another after an account switch. Not implementing cache eviction under storage pressure can cause the OS to terminate the app or exhaust device storage.

Cache-first never hits the network while a cached entry exists — fresh or stale — and only falls back to the network on a cache miss. Stale-while-revalidate always fires a background network request to keep the cache warm, even when a cached entry exists, so subsequent renders get progressively fresher data without blocking the UI.

mermaid

flowchart TD
    A([App requests data]) --> B{Cache entry exists?}
    B -- No --> C[Fetch from network]
    C --> D{Network response?}
    D -- Success --> E[Store response in cache with TTL]
    E --> F[Return data to UI]
    D -- Failure --> G[Return error to UI]
    B -- Yes --> H{Cache strategy?}
    H -- Cache-first --> I{Entry within TTL?}
    I -- Yes --> J[Return cached data immediately]
    I -- No --> K[Fetch from network]
    K --> L{Network response?}
    L -- Success --> M[Update cache and return fresh data]
    L -- Failure --> N[Return stale cached data as fallback]
    H -- Network-first --> O[Fetch from network]
    O --> P{Network response?}
    P -- Success --> Q[Update cache and return fresh data]
    P -- Failure --> R[Serve stale cache as fallback]
    H -- Stale-while-revalidate --> S[Return stale cache immediately]
    S --> T[Fire background network request]
    T --> U{Network response?}
    U -- Success --> V[Update cache]
    V --> W[Push update to UI if data changed]
    U -- Failure --> X[Keep existing cache entry]