Hacker News Reader

Comment by Renat | Hacker News Reader

I'm the CTO of 500px. Decoupling uploaders and converters simplifies the overall design and makes it more robust. Converters are a part of the legacy design that we are planning to retire. In the past, we would generate multiple sizes and crops for every image so it can be efficiently displaced on the site and/or mobile apps.

Today, we rely on the new Resizer service that can resize and crop images on the fly. It's an interesting piece of technology that we will be writing about on our blog: developers.500px.com

View on HN

Thanks for sharing this and being on HN to answer - very interesting architecture! How do you deal with customers from remote locations (Asia, Oceania) complaining about slow upload speeds?

I will keep posted to your blog. Thanks for sharing the link. Always looking to learn about memory heavy operations. Currently am the lead dev on software that revolves around user generated content (images and audio). Its an ever ending road of (fun) challenges.

Is there a specific reason why you didn't use an off the shelf open source solution like Thumbor ( http://thumbor.org/ ) ?

performance is the main reason. Additionally we needed a solution to modify images on the fly (watermarking and attribution). That's why we decided to build our own service using go

I assume you still generate a small thumbnail for every picture, right?

I am surprised that it is faster to resize the image, than to pass the (resized) bits right through. Is the outbound network a bottleneck?

It could be that there are a lot of images/versions that simply never get seen, or seen rarely enough that it's inefficient to store them. And they're being cached by the CDN anyway, so popular images will still only be generated once per edge.

bingo! Extra storage for all the resized images that never get seen, lack of flexibility to introduce new sizes, plus requirements for watermarking and attribution on images are the main reasons why we are moving away from pre-conversion to dynamic image resizing

Generating many conversions for all photos incurs both storage and computational overhead that may never pay off. By only generating the required images on the fly for photos we avoid this overhead while allowing more flexibility. If watermarks or attribution change in the future it's easier to have the resize service in place to handle this as images expire from the CDN than to do a batch job to pre-process the updated conversion requirements for all existing photos.

Also note that photos are stored indefinitely, so any additional permanent storage (new conversions) would add additional storage costs, miniscule as they might be, forever.

Reply on news.ycombinator.com