This kind of analogy is useful to have on hand to explain things to non-technical people, who may not grasp the subtleties of threading vs asynchronicity.
Or for really non-technical people who don't understand scaling and scalability at all, and expect that once you launch, all that's left is adding more features.
The Grocery Checkout is a better analogy for understanding how to tune lower level settings that affect web site performance such as max open file handles, timeout, and total worker threads. Overall you're trying to maximize
* how many checkout lanes are open (total worker threads, max file handles, max port per connection)
* how are customers directed toward the shortest line (load balancing strategy, poll vs. epoll vs. select vs. accept)
* how many items can each customer pay for at once (keepalive, persisting connections)
* how many customers can stand in each lane (receive buffer depth)
* how long to wait for a sleepy customer to put their items on the counter before kicking them out of line (timeout)
You can observe real world traffic jam scenarios in actual checkout lanes and easily picture the same thing happening in a web server stack, and fortunately each layer of the web stack gives you settings to open as many lanes as your servers can handle and keep those lanes moving.
Off topic, but when talking about evented/continuation based systems, I'm surprised the c# approach with the async/await keywords isn't brought up more often. For those unfamiliar, those rather confusingly named keywords make the program compile down to a continuation passing style, while still letting the source look synchronous. Makes the code _much_ easier to handle.
