Furthest from home, the CDNs being used to serve out Steam's site will (as all CDNs do) respect the
HTTP caching headers sent by Valve's origin server(s) and set their behavior accordingly. If you check the main HTML page of any part of their site, it's got the header "Cache-Control: no-cache," while the static resources have headers like "Cache-Control: public, max-age=10516517" (to indicate a page can be cached until a certain amount of time has passed) or "ETag: "XwLMvvR6Hpnl"" (to indicate that the page can be cached until that tag changes.) The correct configuration for a dynamic app with personalized content would generally be to disallow caching of any page with said personalized content, so that each user is pulling fresh from the original server. If something caused the static-asset headers to apply to the application servers, you'd see (correctly configured) CDNs happily caching and re-serving individual users' content to other users. (I was part of a team that broke a company's website -- which luckily had no personalized or sensitive information -- with exactly this sort of change, once upon a time.)
Closer to Valve's side. they're using a reverse-proxy layer to cache and transform content coming out of their application (the Varnish headers are visible in their served pages.) If they're like many people running large, complex apps, they don't just use an out-of-the-box config; they rely on their reverse-proxy layer (or layers) to retag, streamline, encode, and otherwise transform their content before it hits the public CDNs as well as to provide a caching layer. With
the complexities available in Varnish's configuration one can certainly accidentally apply a caching change to pages that shouldn't have it.
Past all that, they most likely also make heavy usage of data caching inside their application. To avoid churning whatever ginormous databases they store all this info in, they probably have some cluster of Redis servers or somesuch which store copies of application data, keyed to unique identifier strings, and only replace it when told to. When a user brings up their Account page, it might create a key that's something like "Steam::Community::ServerId-1234::Account::UserId-4567::Summary" that indicates exactly what information is being pulled, and includes all the key distinguishing features (like which user's data it is) so that the cached data is only used for the right user, and if the application hasn't sent a command to clear out that cache key. This sort of thing is
very easy to break if you aren't looking out for it. It can be something as simple as a botched type conversion on the user ID field -- now all of a sudden your app might be saving and reading from "UserId-0" or "UserId-#ERR?" or something, resulting in every user triggering a read from the same cached record.
We don't have enough information on hand to know which, if any, of these things happened (or whether one of a number of similar possible issues occurred instead), but the behavior we saw today is very much indicative of a failure of caching logic somewhere in an application.
