Mobile caching
Mobile Caching System Design
A cache is a consistency policy with storage attached. Define what stale means before choosing an implementation.
Short answer
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 behavior. 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 behavior and invalidation events.
- Memory or disk lifetime
- Maximum stale age
- Event-driven invalidation
- Eviction and storage budget
- Privacy and deletion
- Fallback when decoding fails
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.
