"... it is not true. I have implemented web caching ..."

As the quote says, it is not the implementing which is hard, it is the invalidating part that is little bit tricky.

If you try to invalidate the cache in a strict manner, you will not enjoy the benefits of the caching much, since it will invalidate most of the time. If you have more relaxed implementation of it, there is a risk of this exact problem happening.

It's possible when you don't realise that something will be cached (for whatever reason - incorrect verb, missing etag or cache-control headers, some cookie confusion), and suddenly everyone starts seeing one person's experience (hopefully only a slightly tweaked page, but at worst their account screen).

Turning the caching off is easy, but it can be really difficult to track down the cause after that because you tend to need a specifically-timed race condition, and even when you're sure you've fixed it everyone is really nervous to turn the cache back on again...

It sounds like some people forgot a `Vary: Cookie` header while they were all running around with their hair on fire because of the DDoS.

I, and many other ops-ish people I know, cringed at the obvious caching error that seemed like the most likely culprit.

The "in the middle of a DDoS" makes it make a lot more sense, and while this is still a cringeworthy situation, the cringing at least on my part is now more sympathetic than horrified.

The hardest is gathering requirements...