Review this. A food-delivery app for low-end Android caches every image it has ever displayed at full resolution in the app's cache directory with no eviction policy, keeps a rolling 90-day local copy of order history for an offline screen almost nobody opens, and bundles four analytics SDKs. Zomato's June 2025 engineering post reports its own consumer app went from a 23 MB download to 15-16 MB and capped a cache that had been reaching 600-700 MB at 120 MB, finding about 100 MB sufficient for home-page thumbnails. What would you remove, what would you change, and what would you leave alone?

What is actually required

Three things, and the design above satisfies none cheaply. Fast repeat rendering of the images a user revisits - the home list and the last few restaurants, not everything ever seen. A download small enough that a user on a metered connection completes the install. And durable local storage for work the server has not yet accepted.

The one change that matters

A hard ceiling on the cache with least-recently-used eviction, and the ceiling chosen from measurement rather than from feel. Zomato's post is useful precisely because it published the measurement: a cache that had been reaching 600-700 MB, capped at 120 MB, with about 100 MB found sufficient for the home-page thumbnails that drive the first screen.

The mechanism that makes an unbounded cache worse than a slow one: the user never sees "your cache is large". They see the operating system saying storage is low, open the settings screen that lists apps by size, and yours is at the top. The action available is Clear Data or uninstall. An unbounded cache does not degrade performance; it converts a storage warning into a churn event, disproportionately on the cheap devices that are the growth market.

There is a correctness consequence teams miss. The cache directory is reclaimable by the operating system at any time, without your process running. Anything the user created there - a queued order, an unsent rating - can disappear between sessions with no error. The outbox belongs in the app's own data directory.

What I would remove

• Three of the four analytics SDKs. Each one is download bytes, startup work on the critical path, a permissions surface and a third party with a copy of your users' behaviour. Four is a decision nobody made; it is four decisions nobody revisited.
• Full-resolution caching for list thumbnails. Cache the thumbnail variant you actually render. Zomato's post reports WebP coming out roughly ten times smaller than PNG for blurred images, which is the kind of per-asset ratio that makes the format choice worth more than the eviction policy on some screens.
• Nothing else. This is a review, not a rewrite; the instinct to also restructure the data layer is how reviews stop being acted on.

What I would leave alone, even though it looks odd

The 90-day order history, if it is text. A few hundred kilobytes of rows is not the problem and deleting it to "save space" trades a real offline capability for a rounding error. Storage is not the enemy; unbounded storage is. The diagnostic is bytes per feature, measured, and a feature that costs 0.3 MB stays regardless of how little it is used.

And full-resolution images for the one screen that zooms. Cache them with a short time-to-live and a small count limit rather than removing the capability.

How I would argue this in the review

With the distribution, not the average. Cache size at p50 and p99 by device model and free-storage bucket, plus uninstall rate against free storage at install. If the p99 cache is 600 MB on devices with 2 GB free, the argument is over. Pair it with the changes that have the best ratio of effort to bytes - Zomato reports app bundles giving up to 22% off download size - so the conversation is about a measured ceiling and two mechanical wins rather than about discipline.

When this is the wrong answer

On a product whose install base is flagship devices with a 256 GB floor, a 600 MB cache costs nothing and the engineering time is better spent on something a user can feel. The constraint is the device population, and it is a number you can look up this afternoon. If the tenth percentile of free storage across your install base is 40 GB, close this review and go do something else.