[billyhoffman]

The bigger question is, why not use elastic infrastructure?

Sure, image optimization is CPU intensive, but their use case is super bursty. When the source image changes, you do multiple optimizations (convert to WebP, lossless JPEG, lossy JPEG quality change, etc), cache the results and you are done. The ratio of "optimizing image" to "serving optimized copy" must be insane.

Dedicated physical hardware feels like a waste.

[skuhn]

[I work at imgix and have helped lead the team on the production issues we face and gathering the details for this blog post]

> why not use elastic infrastructure?

This would have been beneficial (to a certain extent) to solve the over-capacity issue that we faced, but it wouldn't actually be of that much help in an under-capacity scenario. None of our machines are ever idle -- it's simply a matter of how long the work queue gets.

> The ratio of "optimizing image" to "serving optimized copy" must be insane

Yeah, but the serving an already rendered image doesn't traverse our image rendering stack, as you might imagine. That content is cached at the CDN edge (or failing that, within our rendered output cache). We don't re-do work when we don't have to, that's an inherent part of how we keep the cost of operations right and provide our customers with a service of this complexity at this price point.