Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Instagram scaled to 14 million users with only 3 engineers

engineercodex.substack.com

Post reply on HN
Print view View original

191–200 of 202 posts

Re: How Instagram scaled to 14 million users with only 3 engineers

#191

Post by jabradoodle »

BoorishBears wrote: post #186
jabradoodle wrote: post #182

Earlier quoted context omitted.

> Calling out networking doesn't preclude me from mentioning IPC. You made the same point I made as though it was in contradiction to what I said. Adding a network call adds complexity, yes. > A core tenant of microservices is being able to individually deploy your microservices. And why would you not want this to be independently deployable? > You're making my point: If you don't have the engineering chops as a team…

Ah sorry, I guess replying to people supporting microservices by calling out the gaps in technical knowledge they're using to justify microservices is not the same as saying ..."you definitely don't have the skills and resources to start looking at microservices" Ah, wait it is. > And why would you not want this to be independently deployable? Because FAANG has more engineers devoted to managing deployment/observabil…

> Ah sorry, I guess replying to people supporting microservices

Again, at no point did I make an argument for microservices.

> that's just SOA

Absolutely not, from your own reference:

> Each service provides a business capability.

Spinning a high memory task off into it's own process is not a business capability. Microservices are more granluar than SOA services, your describing a microservice.

> That says exactly nothing. At Netflix scale their most random "trivial" endpoints are easily doing scale that entire SMEs won't ever deal with.

You said microservices are for when a microservice would have the support equivelant to a medium enterprise, this is not true even at netflix scale. They absolutely have services owned by very small teams, or else they wouldn't have more than 1000.

> When FAANG is your case study in any technical discussion in a public forum, you're default wrong.

Well who do we use as a case study on microservices then?

> Any useful technical discussion needs...

A technical discussion requires nuance, not turning into a black and white one side versus the other.

Yes, you can have multiple DBs in a monolith, but you tend not to. In microservices you are basically forced to.

It's a crude and expensive way to force modularisation. However, that is still what it often achieves, it gives you infra that you can keep other people away from and lets you be in charge.

Re: How Instagram scaled to 14 million users with only 3 engineers

#192

Post by JimDabell »

tiffanyh wrote: post #187
JimDabell wrote: post #162

Earlier quoted context omitted.

It’s not that they made the same choices again so much as they just re-used Instagram code and infrastructure.

They had the choice of using FB/Hack stack or IG/Python stack, and they choose IG/Python … which is the interesting thing.

The product is basically Instagram but with text instead of images. I would expect that would be the primary motivating factor in choosing Instagram as a starting point rather than the language.

Re: How Instagram scaled to 14 million users with only 3 engineers

#193

Post by leerob »

BoorishBears wrote: post #176
bornfreddy wrote: post #169

Earlier quoted context omitted.

I agree - for most of them. One exception would be React/Vue/other frontend frameworks that split updating the state and visualizing it. It sounds like a small thing, but it makes a world of difference in non-trivial projects, compared to native js / jquery. Then again, it's the idea itself that matters, overoptimizing the implementation is not beneficial. I.e., React classes are just as good (or better) as hooks as…

Vercel and co managed to mangle the one benefit you mentioned. They introduced the concept of a "server component": one that is rendered once and cannot update state. And instead of making that opt-in, they made it the default. — That is to say, the default of React is to no longer allow updating state in components. No value proposition is safe from the forces of financially incentivized thought leaders.

The Meta team introduced Server Components: https://legacy.reactjs.org/blog/2020/12/21/data-fetching-wit...

Re: How Instagram scaled to 14 million users with only 3 engineers

#194

Post by Aeolun »

qaq wrote: post #188
Sparkyte wrote: post #184

Earlier quoted context omitted.

Yeah no I get you. You just want a monolith to be purposeful when you design one. Not multi-purposeful. This is also at the limitation of a programming language. I am kind of kubernetes guy, but I am dying because it relies heavily on a virtualize network distributed. It would drastically increase the performance if kubernetes clusters were built like monoliths and each kubernetes node handled traffic independently.…

Replacing function call with network call does not really solve any org issues. There is pretty much 0 difference if teams are shipping "modules" for a monolith vs a microservice outside of much simplified CI/CD setup in case of monolith. You can gain some scaling efficiencies from scaling services independently but it's a minor advantage for most projects.

> You can gain some scaling efficiencies from scaling services independently

Not necessarily, because if you scale only one of your services all the other services do not benefit at all.

Having microservices would only be better in that instance if they actually consume the resources they are given.

Re: How Instagram scaled to 14 million users with only 3 engineers

#195

Post by BoorishBears »

leerob wrote: post #193
BoorishBears wrote: post #176

Earlier quoted context omitted.

Vercel and co managed to mangle the one benefit you mentioned. They introduced the concept of a "server component": one that is rendered once and cannot update state. And instead of making that opt-in, they made it the default. — That is to say, the default of React is to no longer allow updating state in components. No value proposition is safe from the forces of financially incentivized thought leaders.

The Meta team introduced Server Components: https://legacy.reactjs.org/blog/2020/12/21/data-fetching-wit...

The RFC was driven by Vercel. Vercel announced RSC landing in experimental on stage before the React team even updated their docs

I'm not even going to get into how ridiculous it is that the default config chosen was to break people's builds for a feature that isn't mature enough to have anything more than a single reference implementation from Vercel.

Re: How Instagram scaled to 14 million users with only 3 engineers

#196

Post by ahoka »

elktown wrote: post #125
ahoka wrote: post #114

Earlier quoted context omitted.

Bad input crashes app, monolith fails over, other instance crashes. Full outage. Assuming proper vertical separation, this risk can be reduced by microservices.

It might just as well be increased by microservices due to fragile dependency chains and just different people working async and what not.

Maybe read my comment again.

Re: How Instagram scaled to 14 million users with only 3 engineers

#197

Post by ahoka »

BoorishBears wrote: post #172
ahoka wrote: post #114

Earlier quoted context omitted.

Bad input crashes app, monolith fails over, other instance crashes. Full outage. Assuming proper vertical separation, this risk can be reduced by microservices.

This is not what microservices solve. There'll always be critical microservices that keep your app running. It doesn't matter if all your other services are running if the one serving up core functionality goes down. If your engineering rigor is so poor that you can't get reliable failovers with a monolith, god help you keeping microservices running.

Hence “assuming proper vertical separation”. The same applies to monoliths, so not really an argument.

Re: How Instagram scaled to 14 million users with only 3 engineers

#198

Post by pnt12 »

mcsoft wrote: post #140

The article says nothing about how they instantaneously updated millions of user feeds. It was the most challenging task, as it's way easier to scale reads than writes in distributed systems. Rumor has it early Twitter had a target of 5 sec to update everyone of 50M fan feeds when Justin Bieber touched a screen. I would love to hear some technical details on how they did it.

I remember reading a case study from their engineering blog about this a few years ago - I couldn't quickly find it but maybe it's still out there. It was some think about optimizing for read speed, because one write from a celebrity would cause thousands or millions of reads.

Re: How Instagram scaled to 14 million users with only 3 engineers

#199

Post by elktown »

ahoka wrote: post #196
elktown wrote: post #125

Earlier quoted context omitted.

It might just as well be increased by microservices due to fragile dependency chains and just different people working async and what not.

Maybe read my comment again.

Care to enlighten me? Your comment reads like "assuming the best case scenario for X and worst case scenario for Y, X can reduce the risk". Well, you don't say.

Re: How Instagram scaled to 14 million users with only 3 engineers

#200

Post by acconrad »

> 30 million monthly active users when it was acquired...[they] had just six generalist developers [1]

So they got to 30mm users with 6 engineers...scaling linearly with 5mm customers/engineer. Incredible.

[1] https://review.firstround.com/how-instagram-co-founder-mike-...

Post reply on HN