Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bluesky April 2026 Outage Post-Mortem

pckt.blog

Post reply on HN
Print view View original

71–80 of 85 posts

Re: Bluesky April 2026 Outage Post-Mortem

#71

Post by tombert »

madeofpalk wrote: post #57
tombert wrote: post #40

Earlier quoted context omitted.

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'.

Ok, judging by this job posting [1] it looks like Spotify uses Java as well.

[1] https://www.lifeatspotify.com/jobs/senior-backend-engineer-a...

Re: Bluesky April 2026 Outage Post-Mortem

#73

Post by _heimdall »

fiatjaf wrote: post #49
pfraze wrote: 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.

> no one browses websites through Google's servers.

Didn't Google's AMP project do exactly that?

Re: Bluesky April 2026 Outage Post-Mortem

#75

Post by slopinthebag »

verdverm wrote: post #68
floating-io wrote: post #50

Earlier quoted context omitted.

I don't know enough about rust to confirm or deny that -- but unless rust somehow puts a limit on in-flight async operations, I don't see how it would help. The problem is not resource usage in go. The problem is that they created umpteen thousand TCP connections, which is going to kill things regardless of the language.

case in point, an old HN post about scaling Go to 1M websocket connections https://news.ycombinator.com/item?id=21865715

Go can scale but only if you sidestep goroutines and use something like https://github.com/lesismal/nbio (which is awesome, highly endorse)

Re: Bluesky April 2026 Outage Post-Mortem

#76

Post by chr15m »

numpad0 wrote: post #42
jonstaab wrote: post #13

Earlier quoted context omitted.

1000x redundancy makes it vanishingly unlikely. Although I know we're due for a pole shift so all bets are off I suppose.

Wasn't aware there are ~2k relays now. Have inter-relay sharing situation improved? When I tried it long time ago, the idea was just a transposed Mastodon model that the client would just multi-post to dozen different servers(relays) automatically to be hopeful that the post would be available in at least one shared relays between the user and their followers. That didn't seem to scale well.

A difference with Mastodon is your account is independent of any relay.

> scale well

It is up and it is growing.

Re: Bluesky April 2026 Outage Post-Mortem

#77

Post by jonstaab »

emidoots wrote: post #55
jonstaab wrote: post #10

nostr never goes down

There's stark contrast for an average human visiting the landing page of bsky.app vs nostr.org

That's what decentralization looks like. You might also try:

nostr.com nostr.how nostr.net nostrich.love nostrhub.io usenostr.org And of course https://github.com/nostr-protocol/nostr

Re: Bluesky April 2026 Outage Post-Mortem

#78

Post by arter45 »

nout wrote: post #37
pfraze wrote: post #11

Earlier quoted context omitted.

All support to other decentralizers but nothing never goes down.

The comparison here is to something like TCP/IP. TCP/IP never goes down. TCP/IP is a protocol, the servers may go down and cause disruption, but the protocol doesn't really have the ability to "go down". Nostr is also a protocol. The communication on top of Nostr is pretty resilient compared to other solutions though, so that's the main highlight here. If tens of servers go down, then some people may start noticing a…

That's because TCP/IP is a protocol, not a (centralized or decentralized) server. A protocol cannot go down. It can trigger failures, it can be abused, but it cannot go down.

It's like saying "English never burns". Sure, you can't burn English but you can burn specific books, newspapers and so on.

Re: Bluesky April 2026 Outage Post-Mortem

#79

Post by yangm97 »

jandrese wrote: post #23
jonstaab wrote: post #10

nostr never goes down

If nostr went down would people even notice?

The good thing about nostr is that, contrary to popular federated protocols, your identity is not tied to any single server, you own the keypair to your account, so you can continue using it just fine even if some relays experience a downtime.

Re: Bluesky April 2026 Outage Post-Mortem

#80

Post by numpad0 »

jonstaab wrote: post #46
numpad0 wrote: post #42

Earlier quoted context omitted.

Wasn't aware there are ~2k relays now. Have inter-relay sharing situation improved? When I tried it long time ago, the idea was just a transposed Mastodon model that the client would just multi-post to dozen different servers(relays) automatically to be hopeful that the post would be available in at least one shared relays between the user and their followers. That didn't seem to scale well.

Getting clients to do the right thing is like herding cats, but there has been some progress. Early 2023 Mike Dilger came up with the "gossip model" (renamed "outbox model" for obvious reasons). Here's my write-up: https://habla.news/hodlbod/8YjqXm4SKY-TauwjOfLXS The basic idea is that for microblogging use cases users advertise which relays their content is stored on, which clients follow (this implies that there ar…

Thanks! Not to be critical - more like thinking out loud - and don't have solutions to following myself - but that sounds like it could 1) affect negatively to power concentrating into the top popular relays -> potentially leading to same kind of speech issues as semi-centralized ActivityPub, and 2) it won't solve need to maintain multiple firehose connections.

I've been wondering if the multi-firehose architecture is really where decentralized censorship resistant microblogging should be the way forward; I remember the Windows Mobile clients for 2ch.net(today 5ch.io) that would scrape thread deltas from bunch of subdomains under it was plenty fast on 128k(advertised) connection to get thousands of posts in late 2000s, and so I think an RSS style of systems getting delta updates from multiple domains could work without having to do the insanity of early Nostr, or massive liabilities for instance operators with Mastodon, especially if those multiple domains could be set up with relative ease.

Yeah, I don't exactly understand why you have to sign up every time to Mastodon servers and server operators to have to be responsible about users. It worked when it was urgently needed, which was brilliant, but the ID system had under baked spots.

Post reply on HN