Live data from Hacker News

How meta built the infrastructure for Threads

engineering.fb.com

171–180 of 184 posts

Re: How meta built the infrastructure for Threads

#171

It really irks me when a big company like Meta tries to describe a new project as a startup created by a "nimble team of engineers". In the blog post they link to [1] >Threads was developed in an environment more akin to a startup. OK sure, a small group of people broke the model of development and did something new from the ground up? >Threads scaled successfully to 100 million users without any major downtime thank…

[deleted]

Re: How meta built the infrastructure for Threads

#172

Earlier quoted context omitted.

It's a bot prevention measure (allegedly). It also conveniently blocks out people that are more likely to not want to share all of their personal information with them. No skin off my back, the less toxic social media garbage I'm allowed to use, the better for my sanity, good riddance.

TO BE FAIR (and I'm still on the fence how I feel about this)... the less personal information you share, the more bot-like you appear to be.

Meta/Google/etc... at the end of the day are businesses, and the currency they deal with when transacting with us is our personal information and they convert that to dollars with their partners.

As I also value freedom of association, I am perfectly alright with them refusing to "do business" with me because I do not find the denomination and terms of the transaction acceptable.

I do not really have any inclination to want to compel them to serve me by force of gun, either.

I think both they and myself are better off in this scenario where we just choose to not do business with each other and I find some other business that has more acceptable terms - or I just go without, these services aren't as essential as some people think.

Re: How meta built the infrastructure for Threads

#174

Earlier quoted context omitted.

They are common but not majority opinion. The average Indian is more supportive of Israel for example. That's the most populous country in the world and you definitely see them on X as well. The average Chinese doesn't care about either and doesn't use any foreign social media apps. Many of us have a very selective view of the world. When you have a platform that allows most speech from anyone on the planet, such an…

The Chinese are overwhelmingly opposed to US foreign policy. Outright pro-Israel and pro-NATO views are virtually non-existent on Chinese social media. Some Hindu-supremacist Indians support Israel because of shared Islamophobia, more or less. There is not much rabid Islamophobia outside of the West + India. >They are common but not majority opinion. To suggest that the (powerless) majority of 8 billion humans are no…

I can't speak for US foreign policy, that might be true. I was commenting on your take regarding Israel and Russia, as someone who grew up in Asia - where the majority of the world population lives. A lot of people generally make the mistake of conflating government leadership opinion with the opinion of citizens. Those do not necessarily have anything in common, especially in dictatorships with unelected leaders. The average Chinese does not hate Jews nor do they care much about Russia. The majority have no opinion on this, they could not even find Israel on a map or tell you what the capital of Saudi Arabia is. The state media's reporting reflects the Communist Party's position, not necessarily the position of the people. Although Xi is working hard on drilling the people to make those one and the same.

Re: How meta built the infrastructure for Threads

#175
post #154

Earlier quoted context omitted.

Thank you for sharing your experience and expertise. I'm a big fan of MySQL's scaling properties and some of the tooling (Vitess). Do you see any emergent general purpose RDBMS achieving similar popularity of MySQL and/or PostgreSQL in the near future? I heard good things about Clickhouse but it's a different tool (column based) from my understanding.

I am not a good judge of popularity, given that I still post a lot about MySQL on HN in the year 2024 :) In all seriousness though, as a bootstrapped founder I'm not usually able to devote time to tinkering with emergent databases, sorry! From what I've heard, Clickhouse is excellent, but it is OLAP focused rather than OLTP.

Ahh I see now, you've founded https://github.com/skeema/skeema which is great!

Keep it up!

Re: How meta built the infrastructure for Threads

#176
post #138

Earlier quoted context omitted.

From having talked to Facebook engineers (I suspect Instagram/Threads is a very different beast for historical reasons), Facebook is only built on "PHP and MySQL" in the sense that the statement is technically correct but not helpful. The way Facebook apparently uses MySQL is not "MySQL + k/v store" but "MySQL is the k/v store". Forget SQL, they treat it as a key-value lookup and it's good enough for that. This also…

This is not correct. Facebook has a large number of distinct MySQL tiers, which serve different purposes and have wildly different workloads. None of them are traditional "key-value lookup" workloads, not even the core user database (entities/associations); this k/v claim is often repeated here, but has never been an accurate representation of the architecture. The TAO graph access pattern absolutely requires range s…

>The TAO graph access pattern

Do they still use TAO?

Just wondering if they will ever open source TAO.

Re: How meta built the infrastructure for Threads

#177
post #154

Earlier quoted context omitted.

Thank you for sharing your experience and expertise. I'm a big fan of MySQL's scaling properties and some of the tooling (Vitess). Do you see any emergent general purpose RDBMS achieving similar popularity of MySQL and/or PostgreSQL in the near future? I heard good things about Clickhouse but it's a different tool (column based) from my understanding.

I am not a good judge of popularity, given that I still post a lot about MySQL on HN in the year 2024 :) In all seriousness though, as a bootstrapped founder I'm not usually able to devote time to tinkering with emergent databases, sorry! From what I've heard, Clickhouse is excellent, but it is OLAP focused rather than OLTP.

>given that I still post a lot about MySQL on HN in the year 2024 :)

Not nearly enough So please do that more often :)

Seriously I dont want HN to be one sided about RMDBS and I constantly submit a lot of MySQL related content and release notes. And there is still a whole world using MySQL for a lot of different reasons.

Especially now Oracle has finally updated MySQL release schedule.

Re: How meta built the infrastructure for Threads

#178

Earlier quoted context omitted.

Sounds like something you could do with SQS and Lambda. They just have massive datacenter infra and compute at disposal.

Yeah but what about something that won't make my wallet cry?

Spot and any queue

Re: How meta built the infrastructure for Threads

#180

Earlier quoted context omitted.

Can you share your take on why MySQL and not Postgres?

For me it's mostly about known-knowns. I've been responsible for pretty large/company-critical MySQL clusters and have managed to sleep soundly at night. I tend to be the "database guy" at every startup, and those startups tended to use MySQL. I have to say, I do love PostGIS. But for "this data absolutely cannot be lost or its game-over", I'd go MySQL every time. I can and have debugged MySQL replication on zero hou…

It amazes me how much better MySQL has been in this regard for at least a decade, and it's also amazing that it's still not that well-known today. Back in 2015 I worked at a fast-growing unicorn that had badly implemented basically everything because they started with a tiny ops team of grads and developers. Very little was being monitored, there were only a handful of metrics being graphed (mostly network stuff in Cacti). Our DB issues were all caused by stupid stuff :

* undetected hard disk in array fails

* battery in array controller fails

* disk fills up

* dubious backups, with no point-in-time recovery

* extremely poorly written SQL queries

* poory configured MySQL (in oh-so-many ways)

The top three (at least) would lastly cause replication lag, which would eventually trigger an alert. ... And yet we never lost a cluster. (And we far a lot of them!)

My team sweated blood improving processes and tooling, and then I spent a 6 month stint on database clusters (switching to GTID based replication and rewriting the ops config code so that they were all consistently configured and monitored).

Occasionally we'd get a new senior hire insist that PostgreSQL was a necessity, so we'd stand back and let them produce a proof of concept that stood up to the types of failures our MySQL clusters dealt with regularly, without waking oncall up at night. And it was always a bit of a joke by comparison.

Post reply on HN