Roblog

I recently had to explain the concept of output caching to a non-technical person, and found it surprisingly difficult. There’s so much compounded knowledge that’s required: understanding HTTP; grasping the concept of web servers; understanding that web-pages are generated by some server-side process; understanding that that the result is some HTML, which is then interpreted by the browser and transformed into an interactive web-page.

I struggled for an analogy and eventually stumbled on one that seemed to work; I write it here for posterity, and in case it’s useful to anyone else.

The fast-food restaurant

Imagine we run a fast-food restaurant, serving your usual mix of burgers and fries.

If we wanted to, we could cook fries to order. That is, every time a customer walks in and asks us for fries, we could load up the fryer and cook some fries from scratch. The customer would always get the optimum fry — they could even request for it to be cooked in a particular way, if they wanted to — but they’d have to wait a long time to do it. At busy times, that might mean creating long lines of people, all waiting for fries; eventually, the line might grow so long that people didn’t even bother joining it.

A more sensible solution would be to cook fries for the first customer that comes along, but cook a whole batch of them. We could then put them into a heated tray to keep them warm; when the next customer enters, we just need to grab fries from the tray, rather than having to cook them from scratch. The time taken for each order is much shorter, the line can be processed more quickly, and we can avoid lengthy queues.

But if we cook a lot of fries, we don’t want to serve that same batch forever: it wouldn’t be very good for customers if, at 10pm, we were still serving fries cooked at 11am that morning. So we institute a rule: if fries have been sitting in the tray for an hour or more, we throw them away and cook some fresh ones.

This is a compromise position. Some users still have to wait for the fries, if they arrive at a time when the fries have been declared stale, but since most people don’t have to wait and since people get fresher fries than if we never threw them out at all, it’s an improvement overall.

Translated to the web

Orders for fries, in this case, are like requests for a web page. If we dynamically generate each page, we have the ability to tailor-make that page for its visitor — just like asking the customer how they’d like their fries to be cooked — but this is a slow process. It might take so long that, since there are so many people trying to visit our website, a queue forms; eventually, that queue might get so long that requests time out, just as people might get frustrated and leave the queue for a restaurant if it takes them too long to be served.

Instead, once we’ve generated the page once, we store it in a cache — just like we store the fries in a warming tray. Subsequent visitors to the site can have their page served from the cache, rather than having to wait for it to be generated, just as subsequent customers to our restaurant can have fries from the warming tray rather than having to wait for them to be cooked.

But just like fries, web pages tend to grow stale as time passes. Just as we did with our fries by saying that we would throw them away after an hour, it would be good to set a cut-off point after which we won’t serve a cached page. We do so with a TTL, or “time to live”; the TTL of our fries was one hour, but we might set a TTL for web pages of anything from a few seconds to a few days, depending on how often we anticipate its content changing.

Summing Up

It’s not a perfect analogy, but it helped my particular non-technical marketing bod understand the concept enough to get by; I’d love to hear any other analogies people have used successfully.