All the devices on the planet with Facebook owned apps installed having no concept of backoff retries and people constantly refreshing trying to figure out why Facebook isn't loading was pegging the crap out of DNS resolvers, slowing down queries for other legitimate requests too.

Once they came back online and their DNS was resolving, it alleviated all that pressure.

I did a little testing while Facebook was down. I copied an HN frontpage request from the network traffic tab in chrome’s developer console. Using the ‘copy as curl’ option, you get a fully formatted curl request in your clipboard that makes all of the headers and protocols of the original browser request.

I then executed that request in the terminal. This request was met with the same ~5 second delay I was seeing with my browser. Front and center was my authentication cookie in the header, so I removed that from the command and the request was normal in response time (extremely fast in HN’s case). I put the cookie back, it was slow, I took the cookie out it was fast. I did this 4-5 times until i was satisfied that was it.

The delay could have been due to upstream dependencies on DNS, extra load on the authenticated request pipelines, some Facebook subterfuge in the bowels of HN or just an extremely unusual syncopation in the patterns of the universe.

But clearly the authenticated requests were slow and the unauthenticated ones were not.

DNS resolvers worldwide being bombarded with retries from clients trying to reach FB.

Could it just be people pounding HN for any update on Facebook?

Maybe HN servers share room with something that got pinned down with requests when FB was down? E.g. 100000s of devices doing a login retry loop for some app since FB auth. doesn't work, or something.