Live data from Hacker News

Bluesky April 2026 Outage Post-Mortem

pckt.blog

51–60 of 85 posts

Re: Bluesky April 2026 Outage Post-Mortem

#51

Earlier quoted context omitted.

You can have this problem with any kind of thread -- including OS threads -- if you do an unbounded spawn loop. Go is hardly unique in this. Goroutines are actually better AFAIK because they distribute work on a thread pool that can be much smaller than the number of active goroutines. If my quick skim created a correct understanding, then the problem here looks more like architecture. Put simply: does the memcached…

Rust's async doesn't have this issue. Or at least, it's the same issue as malloc in an unbounded loop, but that's a more general issue not related to async or threading. 15-20 thousand futures would be trivial. 15-20 thousand goroutines, definitely not.

[deleted]

Re: Bluesky April 2026 Outage Post-Mortem

#52
post #49
post #17

Earlier quoted context omitted.

This writeup is useful for backend engineers: https://atproto.com/articles/atproto-for-distsys-engineers The simple answer is that atproto works like the web & search engines, where the apps aggregate from the distributed accounts. So the proper analogy here would be like yahoo going down in 1999.

Sorry, but this analogy is very misleading, no one browses websites through Google's servers. For example, right now in my URL bar I read "news.ycombinator.com", not "google.com/profile/news.ycombinator.com". If Google goes down now I can keep browsing this website and all the other websites I have in all my other tabs as if nothing had happened.

Does Google Reader help you make sense of it? It’s more like each app is like its own Google Reader. And indeed you were able to access the same posts via other apps at that time of outage.

Re: Bluesky April 2026 Outage Post-Mortem

#53
post #49
post #17

Earlier quoted context omitted.

This writeup is useful for backend engineers: https://atproto.com/articles/atproto-for-distsys-engineers The simple answer is that atproto works like the web & search engines, where the apps aggregate from the distributed accounts. So the proper analogy here would be like yahoo going down in 1999.

Sorry, but this analogy is very misleading, no one browses websites through Google's servers. For example, right now in my URL bar I read "news.ycombinator.com", not "google.com/profile/news.ycombinator.com". If Google goes down now I can keep browsing this website and all the other websites I have in all my other tabs as if nothing had happened.

Do you have ideas about how Bluesky could decentralize?

Re: Bluesky April 2026 Outage Post-Mortem

#54
post #49
post #17

Earlier quoted context omitted.

This writeup is useful for backend engineers: https://atproto.com/articles/atproto-for-distsys-engineers The simple answer is that atproto works like the web & search engines, where the apps aggregate from the distributed accounts. So the proper analogy here would be like yahoo going down in 1999.

Sorry, but this analogy is very misleading, no one browses websites through Google's servers. For example, right now in my URL bar I read "news.ycombinator.com", not "google.com/profile/news.ycombinator.com". If Google goes down now I can keep browsing this website and all the other websites I have in all my other tabs as if nothing had happened.

Technically you can still view the posts directly from the PDS. It’s just uninteresting compared to web pages

Re: Bluesky April 2026 Outage Post-Mortem

#57
post #40

Golang's use of a potentially unbounded number of threads is just insane. I used to be fairly bullish on golang, but this, combined with the fact that its garbage collected, makes me feel its just unsuitable for production use.

Why does garbage collection make it unsuitable for production use? A lot of production software is written in garbage collected languages like Java. Pretty much the entire backend for iTunes/Apple Music is written in Java, and it's not doing any kind of fancy bump allocator tricks to avoid garbage. In my mind, kind of hard to argue that Apple Music is not "production use". There are certainly plenty of projects where…

Based on my experience of Apple Music being pretty bad at streaming music, i would say that it's not ready for 'production use'.

Re: Bluesky April 2026 Outage Post-Mortem

#58
post #53
post #49

Earlier quoted context omitted.

Sorry, but this analogy is very misleading, no one browses websites through Google's servers. For example, right now in my URL bar I read "news.ycombinator.com", not "google.com/profile/news.ycombinator.com". If Google goes down now I can keep browsing this website and all the other websites I have in all my other tabs as if nothing had happened.

Do you have ideas about how Bluesky could decentralize?

Not the original poster but I do have some ideas. Official Bluesky clients could randomly/round-robin access 3-4 different appview servers run by different organizations instead of one centralized server. Likewise there could be 3-4 relays instead of one. Upgrades could roll across the servers so they don't all get hit by bugs immediately.

Re: Bluesky April 2026 Outage Post-Mortem

#59

> What I had missed is that we deployed a new internal service last week that sent less than three GetPostRecord requests per second, but it did sometimes send batches of 15-20 thousand URIs at a time. Typically, we'd probably be doing between 1-50 post lookups per request. That’ll do it.

The incredible part about this is because their backend is all TCP/IP they were literally exhausting the ports by leaving all 65k of them in TIME_WAIT, and the workaround was to start randomizing the localhost address to give them another trillion ports or so.

I mean, it's one GetPostRecord, Michael. What could it cost? 1 trillion ports?

Re: Bluesky April 2026 Outage Post-Mortem

#60
post #58
post #53

Earlier quoted context omitted.

Do you have ideas about how Bluesky could decentralize?

Not the original poster but I do have some ideas. Official Bluesky clients could randomly/round-robin access 3-4 different appview servers run by different organizations instead of one centralized server. Likewise there could be 3-4 relays instead of one. Upgrades could roll across the servers so they don't all get hit by bugs immediately.

If multiple personal data servers (pdses) share the same set of posts how would we guarantee that they are tamper resistant to third parties?
Post reply on HN