Mobile caching
Mobile caching system design
A cache is a consistency policy with storage attached. Define what stale means before choosing an implementation.
Mobile System Design Blueprint (book, from $199)
Mobile caching: what matters most
Mobile caching design begins by classifying data by freshness, sensitivity, size and reconstruction cost. Define whether stale data may be shown, for how long and with what UI signal. Memory caches improve repeated access but disappear under pressure. Disk caches survive launches but require schema, eviction and protection rules. Use stable keys, request coalescing and conditional network requests where possible. Invalidate on domain events rather than relying only on arbitrary time-to-live values.
Never cache secrets or personal data without appropriate encryption and deletion behaviour. Measure hit rate, saved latency, stale responses, storage growth and decode cost because a cache can make performance worse when it is unbounded or expensive to maintain.
Write the policy first
For each resource, state freshness tolerance, offline behaviour and invalidation events.
- Memory or disk lifetime
- Maximum stale age
- Event-driven invalidation
- Eviction and storage budget
- Privacy and deletion
- Fallback when decoding fails
Account boundaries and late responses
A profile screen opens fast and shows the wrong account's name. The cache hit was quick and it broke the identity boundary, so the account belongs in the key.
Now the stale refresh. Account A opens a cached profile with a stale label and starts refreshing. The user switches to B before it finishes. The old response still belongs to A. Apply a response only if it matches the request's account and the active generation, and keep disk writes behind the same rule. Clearing the screen at sign-out is not enough if a late writer can fill it again. Arrival order does not always say which data is newer, so two refreshes that finish out of order may need a server revision to decide.
Know what the HTTP directives say
No-cache does not mean do not store. The response can be stored but must be validated before reuse. No-store forbids storage. Private keeps the response out of shared caches. It does not encrypt anything or isolate accounts inside your app. A profile you store yourself is not covered by any of this and needs its own domain policy. Read RFC 9111 before making a protocol claim in the room.
Prevent duplicate work
Coalesce identical in-flight requests and avoid decoding the same large payload for several consumers. Cache transformed assets only when the saved work exceeds storage and invalidation cost.
Images, API documents and derived view models often need different strategies.
Measure the real result
A high hit rate is not automatically good if users see stale data. Track user-visible latency and correctness alongside cache metrics.
During an interview, explain what evidence would make you shrink, bypass or remove the cache.
