Reliability has a price. So does overengineering.

Situation

SmartFrame supported very high-resolution images through a feature called HyperZoom.

To make zooming smooth, we generated large numbers of smaller image tiles at different resolutions.

Eventually those tiles alone took up more than 100 TB.

Storage at that scale gets expensive.

The easy engineering answer would have been to put everything onto the safest, most expensive storage setup available and call it good reliability practice.

I wasn't convinced that made sense.

HyperZoom tiles were generated data used when somebody zoomed deeply into an image.

They weren't the main image.

Normal image rendering and full-screen viewing didn't depend on them.

That made the risk quite different from losing primary customer data or taking the whole image platform offline.

What I did

We looked at the storage workload separately from the rest of the platform.

I had already spent plenty of time working with AWS and discussing fairly specialised requirements with them. Sometimes their services were exactly what we needed. Sometimes they weren't.

For HyperZoom tiles we used Wasabi rather than assuming that every byte of image-related data had to live on S3.

The architecture mattered more than the vendor choice.

We made sure ordinary image rendering did not depend on the HyperZoom tiles.

If that storage path had a problem, zooming could break without making the image itself disappear.

HyperZoom generation was also separate from the primary image path and could later be triggered on demand.

So this was a large amount of reconstructable feature data, with a known blast radius if something went wrong.

And things did occasionally go wrong.

We had an incident where requests for HyperZoom tiles were intermittently failing through the CDN and the problem ended up being investigated across the storage and delivery providers.

I actually like that example because it makes the trade-off real.

We had chosen a lower-cost path.

That path had different operational characteristics.

The important bit was that we had already designed the product so a problem there stayed a HyperZoom problem.

It didn't become a general image-delivery outage.

Outcome

We stored more than 100 TB of generated HyperZoom data without applying the most conservative and expensive storage architecture to all of it.

I don't have a publication-safe calculation that gives me an exact percentage saving from that one decision, so I'm not going to invent one.

The useful outcome is that the expensive reliability tier was reserved for things where the business impact justified it.

And when the HyperZoom path did have issues, the failure stayed within the area we had expected it to.

Normal and full-screen image rendering did not depend on those tiles.

What I took from it

I've never liked blanket reliability targets very much.

Different parts of a system have different value.

Losing primary customer data is obviously a very different problem from temporarily losing a generated zoom tile that can be recreated.

Once you separate those things, cloud-cost conversations get much easier.

Instead of asking whether infrastructure can be cheaper in general, you can ask what you're actually paying to protect.

Sometimes the extra reliability is worth every penny.

Sometimes you're paying enterprise-grade prices to protect something the user barely notices.