Live data from Hacker News

WhatsApp scaled to 1B users with only 50 engineers

quastor.org

291–300 of 462 posts

Re: WhatsApp scaled to 1B users with only 50 engineers

#291

My experience is, # of engineers is directly related to # of product people, which is in turn related to quantity (not quality) of ideas that the founders/leaders are desperate to try out. Higher quantity of ideas == More engineers. Higher quality of ideas == Fewer engineers. WhatsApp success is not about what WhatsApp did, it's about everything they didn't do. No desktop, no browser (until after reaaaaaaallly long),…

I've always called this Feature Cram, and it's standard procedure at basically every company I've ever worked, small and large, B2B or B2C. Nobody is willing to say "Our software is a success and it's done. Let's fix the major bugs, put it into maintenance mode and start a new, separate, great idea!" Nope, instead it's always "OK the MVP is going well. Let's jam ten other unrelated things into it and see what takes off and what are the dogs (and be stuck with the dog features as technical debt forever). Then, when none of them reach the success of the original actually solid idea, they hire moar people and jam 40 more feature ideas in. Eventually, the original great thing that brought the company success is so hard to find and use because of the weight of the other crap, that a new upstart that Just Does One Thing Well comes in and eats their lunch.

Then, at that new upstart, someone asks "What else can we bolt on to this thing to make it really grow??"

Re: WhatsApp scaled to 1B users with only 50 engineers

#292

My experience is, # of engineers is directly related to # of product people, which is in turn related to quantity (not quality) of ideas that the founders/leaders are desperate to try out. Higher quantity of ideas == More engineers. Higher quality of ideas == Fewer engineers. WhatsApp success is not about what WhatsApp did, it's about everything they didn't do. No desktop, no browser (until after reaaaaaaallly long),…

So is SpaceX a low quality idea? Some problems are just not feasibly solved by a handful of people. Does that make them low quality ideas?

Re: WhatsApp scaled to 1B users with only 50 engineers

#293
post #276

Earlier quoted context omitted.

Not true. They were charging $1/year from users in the richer markets. They could easily reach hundreds of millions per year in revenue if they followed this model.

~$30M revenue in 2014 from 600M users. The vast majority of people will leave your service if it goes from $0 to even $1. So no, I don't think they could "easily" scale that up.

Yes, but when I was younger, everyone that I knew, even digital illiterate people, paid that fee. Why? Because WhatsApp was (and is) everywhere.

Re: WhatsApp scaled to 1B users with only 50 engineers

#294

Earlier quoted context omitted.

I believe so, but wasn't it much like the Winrar license where nobody was actually forced to pay at the end of the day?

It was free for the first year iirc, and then a dollar a year. A dollar a year is way more than needed to cover the cost of hosting, and most would spend that to avoid paying for SMS.

They ended up with a billion or two users. $1-2 billion with the subscription is good for a company of a few dozen employees. They could have branched into all sorts of value-add stuff in the future if they wanted to, all without tracking and such even. A simple payments or shopping interface a la Instagram Stores could have done the trick.

Re: WhatsApp scaled to 1B users with only 50 engineers

#295

My experience is, # of engineers is directly related to # of product people, which is in turn related to quantity (not quality) of ideas that the founders/leaders are desperate to try out. Higher quantity of ideas == More engineers. Higher quality of ideas == Fewer engineers. WhatsApp success is not about what WhatsApp did, it's about everything they didn't do. No desktop, no browser (until after reaaaaaaallly long),…

This is a great point, but I'd add that the problem isn't experimentation. Neither is it having a lot of ideas. It's that they aren't using good experiments to kill off most of the ideas.

I think of it in terms of divergence and convergence. Divergent thinking is great. If you think of an army on the march, leaders will be thinking about possible paths and sending out scouts. But when the scouts (experiments) come back with reports (results) they don't just send some soldiers along every path that looks promising. They winnow the options down, converging their thinking.

Bad leaders don't have the discipline for that. And I think a lot of them pick up that habit from sales and/or seeking investment. "What will it do? What won't it do!" That's great for manipulating the feelings of the person you're currently talking to so they'll sign the deal. But it's terrible for running an effective, focused product development organization.

I know I've seen companies die like that. And it's probably way more than we know, because as WhatsApp demonstrates, focusing hard on what's working is a great way to succeed well enough that people study and talk about you later.

Re: WhatsApp scaled to 1B users with only 50 engineers

#296

My experience is, # of engineers is directly related to # of product people, which is in turn related to quantity (not quality) of ideas that the founders/leaders are desperate to try out. Higher quantity of ideas == More engineers. Higher quality of ideas == Fewer engineers. WhatsApp success is not about what WhatsApp did, it's about everything they didn't do. No desktop, no browser (until after reaaaaaaallly long),…

WhatsApp was originally a super simple product. Send and receive messages. It was fundamentally a solved problem. It was all about the fact you could send free messages in a world where sms cost 10 cents a message. It wasn't that their messages were faster, their messages were anything other than free. They had a year fee of $1. Which I never paid yet I used their service anyways. The reason they were able to scale s…

How things would have work around if Microsoft released MSN Messenger for Android and iOS. They had the userbase and the brand already.

Re: WhatsApp scaled to 1B users with only 50 engineers

#297
DuckDuckGo does around 35B searches per year with 160 employees.

https://duckduckgo.com/traffic

Not the same efficiency but it goes to show how certain domains and technology stacks can scale exceedingly well. Plus in DDG case I believe they outsource a lot of their tech to 3rd parties.

Re: WhatsApp scaled to 1B users with only 50 engineers

#298
post #9

This article does very little to explain how they did that. It basically states the type of tech they used (Erlang, FreeBSD and SoftLayer), and something about not trying to over engineer stuff. The title also makes it sound like 500 engineers would make it easier to scale up WhatsApp, which does not make too much sense either.

Hey,

Author of the article here.

Totally agreed. Apologies for that!

The article isn't really "an article" but it's an email newsletter I send out. I'm quite surprised to see it on the frontpage of HN lol.

So what you're reading is one of my emails.

It's meant to be more of a summary with additional links to sources where people can read more if they're interested (emailing people long-form articles doesn't work well as a content format from what I've seen - even ignoring the length limit that email has).

I'll add in some more links for additional reading (like the high scalability post) to give some more detail for people interested.

Thanks a lot for the feedback.

Re: WhatsApp scaled to 1B users with only 50 engineers

#300

Earlier quoted context omitted.

Well true, but my point is that you're not going to be able to scale as successfully as WhatsApp, just by using the same technology stack, if your problem is different. You're right that Erlang was/is the right choice for WhatsApp, and it was most likely picked as the language of choice, because of the smart people working there. It's the same with FreeBSD, a failing startup isn't going to be able to layoff 50% of it…

Erlang was picked for a particular reason. WhatsApp uses a prebuilt open-source chat solution, an XMPP server written in Erlang, ejabberd. This thing was first released in 2003 (old). Already a smart move to get started. I’m pretty sure they hired Erlang developers to dig into ejabberd internals and optimize certain things. They didn’t just decide to become an Erlang shop out of the blue. It wasn’t Erlang that was th…

> I’m pretty sure they hired Erlang developers to dig into ejabberd internals and optimize certain things. They didn’t just decide to become an Erlang shop out of the blue.

Eh, I was there since October 2011, and we didn't hire any people who knew Erlang until much later. All of the early server engineers (including me) learned it on the job. By the time I left in 2019, I think we hired two people to the server team with previous Erlang experience; it's hard to find people with it, and while it might have been nice, it's not important.

It's possible we had some consulting possibly before I was hired, but I don't remember seeing any evidence of that; OTOH, I do remember setting up and working with a FreeBSD consultant and Moxie when he was consulting on end to end. From my understanding, when things started bottlenecking, Rick Reed was hired to fix bottlenecks; which he had been doing at Yahoo! for many years and had worked with Jan and Brian there.

FWIW; WhatsApp the service started as just a text status, built on PHP and MySQL, but people were using it to chat, so the founders went looking for a chat server to use rather than building one from scratch. I don't know the decision process, but ejabberd was then powering Facebook chat at the time. (Of course, Facebook abandoned Erlang, they said because they couldn't find people with Erlang experience to hire)

Anyway, by the time I got there, I was told that the chat server had been mostly refactored over time and while a lot of names remained the same, and some of the basic architecture was the same, it wasn't ejabberd anymore. Mostly I worked on things that weren't chatd, and I don't think I've seen ejabberd code, so I can't verify, but it seems likely, as we customized the protocol, auth, offline messaging, contacts, session handling, etc.

Erlang is a tremendously right fit for a chat server, and hot code loading is almost necessary when you have hundreds of thousands or millions of connections per chat machine and want to push small changes. Of course, changes to BEAM itself, or the OS kernel take restarts, so you still need to do those from time to time.

Post reply on HN