Hacker News Reader

Comment by redrove | Hacker News Reader

>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.

View on HN

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.

It's not features you'd be missing but userbase

Not only, most of twitter’s features are in fact not public facing and are those which are making money.

Public facing features are just the loss leading part of Twitter. It’s even probably a little portion of the company’s code base.

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 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

That would be George Hotz.

Text-book of how it takes more than just technical skills to get things done.

George Hotz. Here's an HN discussion about when he joined: https://news.ycombinator.com/item?id=33723257

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.

https://news.ycombinator.com/item?id=34074344

His resignation four weeks later.

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.

So you are describing aws. The problem of infra is that you need someone to run it. Until then, either run it yourself or pay someone to do it

AWS doesn’t give you automatic 100% of NFRs, it just gives you more options in the trade-offs. For example, doing a database upgrade safely.

They have at least 2 web clients, iOS and Android native apps and this is not even taking into account analytics, ads or spaces.

What's included in that 90%? Because I don't think the "What is happening?!" form and the timeline quite cut it.

> 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.

Everyone forget about back office functionalities, like content moderation, user verification, etc. That also applies the pareto principle, 80 20

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 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).

Large Company Used Its Employees And Assets To Ship A New Feature, indeed.

Who’d have thought of that

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.

That explains why it just feels like a worse version of Instagram.

Yeah, and that has downsides they admit!

> 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...

Reply on news.ycombinator.com