Thanks for your comment. I'm really interested in this topic. How do you know the web server is Django? I searched but couldn't find this.
Why would they use Django? I did some small projects in it but I assumed it wasn't very fast and wouldn't be suitable for a big app like this. I would like to know the pros and cons. Why didn't they build up something in C++ or Rust? Won't python limit the speed of responses despite being build the hard stuff in compiled languages? Sorry for being so naive, I am an amateur.
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.
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.
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.
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.”
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.)
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 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.
Why would they use Django? I did some small projects in it but I assumed it wasn't very fast and wouldn't be suitable for a big app like this. I would like to know the pros and cons. Why didn't they build up something in C++ or Rust? Won't python limit the speed of responses despite being build the hard stuff in compiled languages? Sorry for being so naive, I am an amateur.