At least a few years ago, most of Instagram’s server side code was in Python. Python may be slower than C++, but it’s not about raw speed it’s about being “fast enough.”

It is fairly normal to build web servers in a way so they can be scaled horizontally (more instances rather than larger instances). So they can just have more containers run their Django servers and distribute the load between them.

They deemed getting to the market fast was more important than hardware costs. If their architecture is good, then they were probably really quick and flexible using Python to glue their architecture together which would have been the development bottle neck to getting the service up and running. All the components of the service can be done by separate teams in whatever language they deem most effective.

Most of Facebook is built on PHP. I’m surprised they didn’t choose Laravel.

Laravel is not a requirement to use PHP effectively.

Oh, I know. But as a joke I chose the most well known framework.

Personally evren I prefer php over python.

Laravel wasn't created until 2010/11~

It turns out calling the app "Threads by Instagram" is not just a branding gimmick. The Instagram backend was always Python/Django since before the acquisition.

That's pretty interesting, I wonder if that means that it's build by a team at Instagram, and not Facebook. I'd assume so.

I get that Facebook is still a huge success, but I do find it telling that they opted to put Threads under Instagram, rather than Facebook.

I think its pretty obvious they went with Instagram branding, as Facebook branding has been tarnished for a while.

I'm confused.

It's Facebook by Meta. Instagram by Meta. Why isn't it Threads by Meta?

Tied to ig account.

Threads by Instagram by Meta ... TIM for short.

The web codebase was once written in PHP, but they moved away from that a decade ago.

It’s still very similar to php. Same syntax, same execution model. If you look at some hack snippets you would think it’s php (because it mostly is).

Switching from hack to php and viceversa should be extremely easy.

That being said, they chose python because Instagram is written in python, they are probably using a lot of existing libraries.

That wouldn't even make sense. They created hack/hhvm to scale and optimize the platform and codebase. Taking a step backwards and refactoring (hack != php now) would be a horrible idea.

Whether it's in C++ or Rust or Python, almost all of any slowness would be from database waiting anyway.

It wouldn't. Databases are fast, python is slow.

Network is slow. So you are waiting on the db for most of a request lifecycle.

That depends on how much work is done in stored procedures instead of wasting network traffic and client CPU cycles to process the results.

Network latency within an AWS AZ is <1ms and throughput is in the GB/s range.

What percentage of python webapps do you think are hitting this as their latency and throughput limit?

(Assuming effective DB use of course, i.e. not doing dozens of DB roundtrips to server a single result or getting megabytes of data and filtering on the client etc.)

True... When I measured something similar in a large python app, the biggest chunk of time went into python object serialization/deserialization.

Not really. Look at Techempower web benchmarks.

I worked at IG on a previous iteration of Threads, with some of the engineers who wrote the current Threads app. It's Django!

(Heavily modded, run on a custom Python JIT, and using an extremely custom FB-developed database, also used for IG and FB.)

It's Django because IG was originally written in Django back in the day. FB's general approach to scaling is keep the interface generally similar, and slowly replace things behind the scenes as necessary — rather than doing big rewrites. It's seemed to work pretty well.

Ultimately the language used for the web server isn't a huge deal compared to the performance of the database, for these kinds of massive social apps. Plus, well, they do have the custom JIT — but that's very new, and when I first joined IG in 2019, we were running vanilla Python in production.

Thank you, awesome answer! HN comunity is awesome.

Thanks also to every other answer I received for my question, I appreciated all of them.

To answer the first, because I am no longer bound by nda.

Why Django? Because that's what it originally was. Same with YouTube frontend btw. The apps just grew and grew.