Live data from Hacker News

Why Twitter didn’t go down: From a real Twitter SRE

matthewtejo.substack.com

891–900 of 1001 posts

Re: Why Twitter didn’t go down: From a real Twitter SRE

#891

Earlier quoted context omitted.

> removing engineers won't instantly crash the product. It'll happen slowly It's amazing to me how many people following the Twitter saga, some familiar with or actually working in technology, thought that Twitter would crash within days of the engineers being fired. And because it didn't, the job cuts are justified.

Quoted post unavailable.

No post body was provided.

Re: Why Twitter didn’t go down: From a real Twitter SRE

#892

> This left a lot wondering what exactly was going on with all those engineers and made it seem like it was all just bloat. I was partly expecting the rest of the article to explain to me why exactly it wasn't just bloat. But it goes on talking about this 1~3-person cache SRE team that built solid infra automation that's really resilient to both hardware and software failures. If anything, the article might actually…

I guess different definitions for "bloat" but how is it bloat to have a tiny team taken care of a fundamental piece of infrastructure? if the team is now gone, an issue there would mean hours of downtime. If that's acceptable then yes, it was "bloat".

Re: Why Twitter didn’t go down: From a real Twitter SRE

#893

Once thing I've seen that I think is overlooked in the whole "is Twitter's tech stack inefficient" chat is the nature of the service. A lot of the "Twitter could be run off my laptop" style comments seem to come from people who run, effectively, Read-Only services. They might serve data at thousands of queries per second but the data itself is _slow_. It is video files or music streams or other data that updates infr…

I've heard this elsewhere, and when Twitter was originally founded in 2006 it wouldn't have been a particularly hard problem. Twitter processes roughly 10K tweets per second. Even if you bloat out the text quite a lot to account for encoding overheads, metadata, etc, etc... and assume that each one is 10KB, then this is just 1 Gbps. A single NIC on an old server. Okay, I get it, Twitter needs a lot of data too. Lists…

That's looking at Twitter from the other end, as a Write-Only service with non-realtime requirements on the read layer.

Twitter is both sides. Tweets are replicated out in milliseconds. Twitter search is lightning fast, comprehensiveband powerful. o Old tweets are not just glaciered into S3!

Re: Why Twitter didn’t go down: From a real Twitter SRE

#894
post #719

Earlier quoted context omitted.

> thought that Twitter would crash within days of the engineers being fired Because they work for companies where the product would fail within days of them being fired themselves.

That's what people keep telling themselves. Truth is, everybody is replaceable. And usually, loss of institutional knowledge takes a while to show real effects.

The dangerous piece of this is executives who don't have a solid grasp of how things are operating can assume that a product still running after the departures is still successful. Validates their decision making even as things deteriorate in the background.

That said you can replace people and build back that institutional knowledge -- both loss and gain take significant amount of time.

Re: Why Twitter didn’t go down: From a real Twitter SRE

#895

Earlier quoted context omitted.

> the article might actually persuade me that it was all bloat First of all, how does it persuade you of that? The article touches a really small (though incredibly important for up-time) subject. Secondly, in any large company, the majority is 'bloat'. It's security engineers, code reviews, data architecture, HR, internal audit teams, content moderators, ccrum masters and I can keep going. In a start-up many of thes…

How difficult can a platform like Twitter be? I am convinced you can run the entire tech stack with a team of a 100 people.

George Hotz thinks it's even less, on the order of 20-40 engineers.

"20 with cloud, 40 without. So much overlap between iOS, Android, and the web, three people can do all three. More for the backend." https://twitter.com/realGeorgeHotz/status/159371372367535718...

Re: Why Twitter didn’t go down: From a real Twitter SRE

#896

Earlier quoted context omitted.

A lot of people who don't understand why Twitter owns two datacenters point to "complexity" as an argument and completely disregard scale. It turns out that massive scale adds a lot of complexity to a system, particularly around many-to-many pubsub systems (like social media). It also means a lot of features, like compliance with government regulations around the world.

WhatsApp had a Billion users and 50 employees. You can say that Twitter is incrementally more complex due to wider broadcasting, but it’s also 1/5 the user count. Everybody stating this number of employees is necessary to maintain a Twitter scale system is simply wrong. And as technology progresses, fewer and fewer people are needed to maintain the same size system Many just don’t want to believe that the leverage in…

Whatsapp, discord, telegram, and all other chat apps have a very easy time scaling. Using user count as a metric and comparing them to Twitter is pretty disingenuous. Instagram is a much better comparison, which had 1/50th the user count of Twitter at its acquisition.

Chat apps are well known to rely on infrastructure that scales up exceedingly well. That is why there are so many of them, and why they all have 100 tech employees or less.

Instagram at the time of the acquisition could have run on 20 servers plus S3. Today's Instagram, along with today's Twitter, does a lot of work that is super-linear in user count, and has something like 2000 engineers. Timeline building is reportedly O(n^2) in user count. The scale difference has a huge effect.

Notice that chat apps have no equivalent to "timeline building." The worst scale factor a chat app has is linear.

Re: Why Twitter didn’t go down: From a real Twitter SRE

#897

> This left a lot wondering what exactly was going on with all those engineers and made it seem like it was all just bloat. I was partly expecting the rest of the article to explain to me why exactly it wasn't just bloat. But it goes on talking about this 1~3-person cache SRE team that built solid infra automation that's really resilient to both hardware and software failures. If anything, the article might actually…

I’m suspicious that most of the value in these systems comes from a small fraction of the effort and many technology jobs boil down to knowing you’re a huge cost center and putting on a performance to hide that.

Re: Why Twitter didn’t go down: From a real Twitter SRE

#898

Earlier quoted context omitted.

> the article might actually persuade me that it was all bloat First of all, how does it persuade you of that? The article touches a really small (though incredibly important for up-time) subject. Secondly, in any large company, the majority is 'bloat'. It's security engineers, code reviews, data architecture, HR, internal audit teams, content moderators, ccrum masters and I can keep going. In a start-up many of thes…

> In a start-up many of these roles can be ignored, becaus growth > stability. In a large organization, part of the bloat helps insure a certain amount of stability that's necessary to keep an organization alive. It also (a) increases the bus factor, [1] and (b) allows people to take vacations and time off without having to watch their phones like hawk. [1] https://en.wikipedia.org/wiki/Bus_factor

I know the bus factor is the morbid "how many people can get hit by a bus?" idea, but I actually like to present it as "how wide is the bus?" in terms of people being the conduits along which information and instructions flow; a wider bus provides redundancy. Aside from being more positive I think it's also more accurate for how we want teams to work. The "win the lottery and quit" metaphor is just stupid.

Re: Why Twitter didn’t go down: From a real Twitter SRE

#899
Linear extrapolation seems to be a common theme in the comments. People take a product they know and then essentially say “Twitter only has X times as many users, surely they only need X times as many engineers. The other employees were excess!”

I haven’t worked on Twitter-scale products. But I do wonder if it’s safe to draw a straight line between services that have middling and large scales. Things don’t necessarily work the same at the extremes.

Re: Why Twitter didn’t go down: From a real Twitter SRE

#900
post #873

Earlier quoted context omitted.

Quoted post unavailable.

Weird to hear the work culture that involves being nice to people being called the toxic one.

https://en.wikipedia.org/wiki/Toxic_positivity

Breathtaking niceness going on from lovely stable people:

  apartheid profiteer, dictator's asskisser, insecure colonizer, cruel hoarder, mediocre manchild, petty racist, supreme parasite, petulant pimple
https://www.msn.com/en-us/money/companies/meet-the-projectio...

  The projections were the work of Alan Marling, a Bay Area activist who declined to give his age or comment on his profession. He stood nearby — donning a Captain America face mask and a Sunrise Movement beanie — as passersby, many of whom were tech workers getting off work from nearby offices, stopped to take videos and photos.
https://www.sunrisemovement.org

https://en.wikipedia.org/wiki/Cult

https://en.wikipedia.org/wiki/Sam_Bankman-Fried

Post reply on HN