>The company leveraged Instagram's existing monolithic architecture and quickly iterated to create a new text-first microblogging service in record time.
So they, in fact, had already built out Instagram as a monolithic service based platform and essentially forked it, tweaked it, tested it, and shipped.
The title of the article is highly misleading, suggesting they shipped from 0 to full platform in 5 months explicitly due to the fact they were using a monolithic architecture as opposed to a microservice based one.
0 to full platform in 5 months doesn’t seems impossible when you are Meta, especially for a Twitter-like.
Still impressive, but the hard part of launching a Twitter competitor is not technical, especially when you already have a virtually infinite amount of already competent developers and infrastructure and when you don’t need the product to make money asap.
The hard part is launching it commercially and giving it enough momentum.
Like the adage says, I can code Twitter in a weekend but it will not be Twitter and it will not magically make money.
I reckon I could implement 90% of the end-user functional features of Twitter in a weekend. The remaining 10% of the features would take at least another year, and the non-functionals (performance, reliability, observability, scalability, etc) would take me a lifetime. But that second sentence turns Twitter from a useful little tool into a valuable product.
Precisely. Most of the developers, including seasoned ones look at an application and say I can build it over a weekend. Yes you can. For your own use. For it to become a real product which is stable and scalable, takes much more time and effort.
I think you mostly describe the problem with modern web development. There are frameworks and tools that makes implementing Twitter in a weekend possible. What we need is to make the non-functionals (performance, reliability, observability, scalability, etc) part 10-100x easier to scale.
You’re right, I didn’t even think about these! I still wouldn’t include them in end-user facing features, but try are certainly necessary to be a valuable product at Twitter-scale.
> I reckon I could implement 90% of the end-user functional features of Twitter in a weekend.
Building a Twitter clone is an exercise that's frequently used in system design interviews. It's a popular exercise because it's a trivial system to implement to meet client-driven requirements, but the feature set becomes progressively more complex when scale, performance, and business requirements are thrown into the mix.
I think someone complained about twitter search to elon musk when he took it over saying how he could fix it easily. From memory, he left pretty quickly and said ihe was unable to fix it
The top comment is funny in retrospect. "He already removed the login prompt which was a huge annoyance as a read only user of twitter." Twitter is now significantly more unusable as a read-only user, as you can't see beyond the first tweet in a thread.
I use FB since cca 2008 (now much much less), and it has been various bugfest throughout the years, till these days. I don't mean unexpected confusing behavior but outright bugs. Comments added twice or not added, some images not uploaded into albums, stuff disappearing right in front of me when writing comment, double notifications for the same, page just dying and so on and on. No issues anywhere else, its not due to sloppy internet connection. I talk about desktop web client, removed anything from meta from phone long ago and not going back.
If it wouldn't be for the social part of connecting with long-lost folks from the past, I wouldn't use a service that behaved like a student project for decade and a half.
So actually shipping something working, and so fast, by same folks, is indeed impressive to me (not sure if same sort of basic bugs are there though, I am generally in direction of moving away from these 'social' platforms that actually in my view makes us as whole society more antisocial, we are simply built for physical interaction on many levels, we thrive with it and wither away without, even us introverts).
TBH, it could take more time to clone and tweak a micro-service architecture.
Arguably, they'd take another approach altogether in that case (keep some services in common and clone as few services as possible for instance), but it's still notable that they had the option to clone it wholesale in the first place.
Yeah this is like working for Google and launching "YouTube Texts" where some engineer removes all the actual videos leaving only the code for comments and calling it a new thing.
> Despite the apparent advantages of reusing Instagram's platform for Threads (much faster delivery time), Malkani admitted the company introduced a substantial amount of technical debt that must be addressed in the future.
If they forked Instagram for Threads I bet the codebase is WAY more complicated than it needs to be.
yeah, nothing special about infrastructure indeed... They just reuse IG infra and build features on top of it. Mentioning Microservices is so non-sense here, just for the purpose of clickbait.
Remember, microservices refers to the architecture of people. It is the emulation of the service architecture found in the macro economy (i.e. businesses buying and selling services with each other without any direct coordination), but localized in the micro economy of a single business.
There is a prevailing idea that large organizations do not have the communication capacity for many people to all work together, believing that more people require more meetings to coordinate, which at some point reaches a critical mass where any change requires more meetings than there is time in the day. Teams emulating the macro economy – a world where you can't get Google on the phone no matter how hard you try, where all you get is written documentation – is thought to be the solution to that problem.
So there would be something novel about multiple, disparate teams showing they can all work together under direct coordination while actually getting things done and not get bogged down in endless meetings. But, while the article is light on details, it appears that they actually did stick with a microservices model – creating a copy of Instagram so that the Threads team could provide an independent service without needing to communicate with the Instagram team...
So they, in fact, had already built out Instagram as a monolithic service based platform and essentially forked it, tweaked it, tested it, and shipped.
The title of the article is highly misleading, suggesting they shipped from 0 to full platform in 5 months explicitly due to the fact they were using a monolithic architecture as opposed to a microservice based one.