Might be interesting to write a follow up on what went wrong though if you can do it without pointing fingers. Post-mortems can be a valuable resource as well.

I’d also be interested in hearing about what you did on the server side in anticipation of the loads. I noticed a bit of lag with thmbnl on your main page…

Great job on what looks like a really nice app.

7M a day would cost us $33,000 a month under your plan. That is the same cost as a yearly staff of 3.

Even for a small blog, 1000 views a month means only 33 visitors a day.

The application and website are on separate machines, so if there was lag, it could have been anything between your browser and the first time hitting the website. Thumbnail making activity won’t affect the site itself.

@Alice: The key is ‘depending on caching’, and the nature of a utility service. If I signed up for electricity service and left all my appliances and lights running all the time, I’d feel that power was priced too high. If I use it judiciously, then it works out. The same goes for caching with thmbnl – it’s an essential part of making good use of the service, but it’s up to developers to implement it, whether they’re writing for a blog or a site with 500k page views a day.

This would also be the case if you were using Amazon Web Services like S3 for your site. If you stored all your pages there and served them all out from S3 for each visitor, S3 would be priced totally out of line. If you made use of caching it could be pretty reasonable, moreso than running everything on your own hardware.

Not true about S3; I know plenty of sites that use S3 as the edge image store, because it’s distributed (and cheap).

If you’re saying that I am supposed to still cache the thumbnails and serve them locally, then it’s easier to just generate them locally in the first place.