Basically they're a silicon valley company who've done everything that's exactly the opposite of standard silicon valley advise -- bootstrapped for first few years, complete apathy or even aversion to silicon valley marketing (if you live in the valley and have no foreign connection, you probably didn't even know what whatsapp was before 2012 or so), built for all client platforms simultaneously (including blackberry and Nokia), focus on non-US markets first, built out on leased hardware instead of public cloud, a simple pay-for-use business model selling to <i>consumers</i> (before facebook bought them), deep aversion to ads (<a href="http://blog.whatsapp.com/245/Why-we-dont-sell-ads?" rel="nofollow">http://blog.whatsapp.com/245/Why-we-dont-sell-ads?</a>) etc. The fact that their technology stack ended up being Erlang on FreeBSD is probably the least distinguishing feature about them.
Comments in this thread are quite cringeworthy. People calling WhatsApp a simple application seem to fail to understand the cost of simplicity under such scale.
If this isn't a counter to the inane recruiting requirements of "5 years with language X" I don't know what is:<p><i>We don’t bring them in specifically because the engineer knows Erlang,” Mahdavi said on Monday. “We expect the engineer to come in and spend their first week getting familiar with the language and learning to use the environment. If you hire smart people, they’ll be able to do that.”</i>
I'm surprised that nobody mentioned why whatsapp started with Erlang in the first place. They started out with an open source xmpp package. The most popular one at the time happened to be written in Erlang (ejabberd). There was no masterplan to scale to close to a billion accounts.<p>As it happens, Erlang is an excellent platform upon which to build a message exchange service. Also, the article doesn't mention their completely non-traditional approach to ops. Despite the conventional wisdom in the valley, they run their own servers. And squeeze an enormous amount of value from a small number of servers. Their unique ops strategy is probably as much a part of their success as simply using Erlang.<p><a href="http://www.erlang-factory.com/static/upload/media/1394350183453526efsf2014whatsappscaling.pdf" rel="nofollow">http://www.erlang-factory.com/static/upload/media/1394350183...</a>
I don't quite understand the correlation. If the article was about how Whatsapp achieves scale and parallelism through functional languages, then fair enough. But I'm not sure it's fair to say they need 50 engineers, in part, because of the language choice ? Surely they need 50 engineers because their product is fairly simple and there's no need to have more engineers than features. Maybe the point it should have made is that Whatsapp values higher quality over quantity ? That I could relate to.
Isn't it more because they're a simple IM application (albeit spread across a number of platforms)? I know they're hugely successful and there are considerations about scaling to that sort of size, but surely the fact that their product is extremely simple has to be a huge factor?
(Disclaimer: I teach this stuff) Good article. It's a keeper. Touches on a lot of things I've been telling clients for years.<p>My takeaways:<p>- Pure functions in little composable pieces. Screw the fact you can't find programmers. With 1/20th the staff, it's not important<p>- Zero to few meetings. Keep focused on one thing. No playing around with WhizzBang Platform 7.0 because all the cool kids are using it. Mind your knitting.<p>- Keep It Simple, Stupid. Engineers are our own worst enemy. Solve the most simple problem possible. Then add complexity a little bit at a time, only as a last resort. For those of you saying "But messaging is solved", "Erlang was written for messaging", and so forth, this is where you missed. Any complex system (with a few notable exceptions) will look very simple when solved in this manner. In fact, that's the entire point.<p>- Running and deploying are the same thing. CI/CD. There is no Big Red Button to push because we're always working on the airplane engines while the plane is flying<p>Coming from a traditional OOA/D/P background, this mentality was extremely foreign to me. Even though I was using and talking about TDD, it was still in terms of composing and re-arranging object graphs. It wasn't until I got into F# several years ago that the pieces started coming together. This is a very difficult conceptual leap to make, because a lot of the ways you work looks completely ass-backwards to folks who are used to doing it the other way.
Here's part of what I don't get - there are so many government organizations, state and federal, jumping over themselves to provide funding, incubation and support to IT product/app companies across the country claiming it creates jobs when, as this shows, it is entirely possible to operate at incredible scale nowadays with a mere skeleton staff. So why do so many government-run and government-funded programs fawn over such companies when their ultimate goal is job creation and these companies are designed to run with barely a couple dozen people at most?<p>This has nothing to do with private VC's; I completely understand why they are in the game. I'm talking about government programs or government-funded NGO programs that provide tax incentives and other funding or support to startups in the product/app space hoping it will create jobs. Maybe this isn't every state, but where I live this is the case.
For reference here is a talk they did about how they scaled WhatsApp and the problems they faced:<p><a href="http://www.infoq.com/presentations/whatsapp-scalability" rel="nofollow">http://www.infoq.com/presentations/whatsapp-scalability</a>
I got my first ever spam on whatsapp the other day from someone who had never been a contact, and there seems to be no way whatsoever to prevent it. So maybe they should hire 1 more engineer to work on spam.
> Why WhatsApp Only Needs 50 Engineers for Its 900M Users<p>Answer: because sending short messages from A to B is basically a solved problem. There is even a programming language (Erlang) that was made with this application in mind. The prototypical "Hello World" example for Erlang is a messaging application.
"WhatsApp doesn’t talk much about its engineering work" - Wrong as hell.
They first talked about this in erlang conf about 3 yrs ago, in 2012. [Youtube Link]( <a href="https://www.youtube.com/watch?v=wDk6l3tPBuw" rel="nofollow">https://www.youtube.com/watch?v=wDk6l3tPBuw</a> ).<p>I hate how tech blogs take a thing thats quite well known and old and spins into a "did you know?" post like it was just unraveled (Oh, maybe your staff just heard about it, doesnt mean no one knows shit.)
Worth reading, especially the stuff that is linked:<p><a href="http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html" rel="nofollow">http://highscalability.com/blog/2014/2/26/the-whatsapp-archi...</a>
Yup, Erlang. If I move on from Python as my main programming language of choice, it would be to Erlang. So many are enthralled by Go and I never saw it. The Google association helps for those that idolize the corporation. Others feel Java is all we need or C# is all we need. Or JS and C++ and call it done. Some want to JS all the things.
Erlang is a bit niche but it's indispensable like C, and Python is just such a great gen purpose platform.
The most value is in the C/Python/Erlang triforce.
WhatsApp seems to be a great example of designing your system with the best tools available. To go from nothing to pretty much being the de-facto modern replacement for SMS in a couple of years is an amazing achievement.<p>I really need to sit down and spend some time properly learning a functional language. I can hack my way through Haskell code but I do it in a very non-Haskell way. I really need to change that. My primary language is C++ and I am open to any recommendations for what direction to go in :)
Because adding more engineers will make the development slower (<a href="https://en.wikipedia.org/wiki/The_Mythical_Man-Month" rel="nofollow">https://en.wikipedia.org/wiki/The_Mythical_Man-Month</a>).
There are more than 50 engineers working to support WhatsApp. A complete count should include all of the work that was out-sourced, such as engineers at AWS (or whomever is supplying the computing), the engineers for Erlang, etc. If the government builds a bridge by using a construction company, no one says the government is capable of building a bridge with zero engineers.<p>The app is still a remarkable achievement. Those engineers have done a remarkable job integrating everything (plus their own business logic on top), but they are also leveraging a great deal of work done by others.
On a side note, there is a Chinese Internet messaging software called QQ developed by Tencent (which later developed WeChat). it had hundreds of millions of users about 8 years ago, and it runs on multiple platforms, including Nokia, Android, etc.<p>So the point is that it is not surprising for a similar app to be developed 5 years later by a small group of people.<p><a href="https://en.wikipedia.org/wiki/Tencent_QQ" rel="nofollow">https://en.wikipedia.org/wiki/Tencent_QQ</a>
"Code in Parallel
In using Erlang, WhatsApp is part of a larger push towards programming languages that are designed for concurrency, where many processes run at the same time."<p>Concurrency is not parallelism! /whacks author over the head with a Go manual
Language/platform choice explains why they need 50 engineers rather than 100. The trivial scope of the application explains why it's 50-100 and not 5000. It's a messaging service! If they weren't extending their application by developing new functionality then 50 even sounds like a lot (assuming they don't run any of their own hardware).
This articles doesn't look that convincing to me. I has no technical details to prove that Erlang was the major reason why WhatsApp was scalable. I think the low number of engineers has more to do with the simplicity of their product than with this particular language choice.
I have to say I was expecting this to be a little older - it's really impressive that Facebook have kept the culture and tiny headcount of that team.<p>I doubt it's ever a good idea for a company like Facebook to do layoffs but I wonder if there are any lessons from the WhatsApp team for a company that size - their intern cohort looked way bigger than 50 and they seem to have almost 50 offices [0]. Obviously a very different product and much more complex but it's interesting to wonder what the same product led by Jan Koum would hypothetically look like.<p>[0] <a href="http://newsroom.fb.com/company-info/" rel="nofollow">http://newsroom.fb.com/company-info/</a>
I wish there were some good online resources around Erlang. Most of the content is very theoretical and not explanatory. Its hard to find implementation of common algorithms like Sorting, graphs, link-list and other dataStructures in erlang.
The language and culture of simplicity are great aspirations, all companies should look at doing this. However, not all companies are going to get such a huge benefit, as not all companies operate within a narrow problem domain. INSTAGRAM is another similar case: relatively simple solution (share photos with limitations), uses only single language PHP (at least since last I heard).<p>I mean this is partly a reflection of the teams brilliance, and the foresight. But its also that the operational cost is relatively low compared to a payroll system that needs to abide by government regulations and reporting requirements (for instance).
I think part of it is their awesome product design: their app has few features, but they are well thought out and enough to make WhatsApp very useful. Fewer features mean less people needed for development and operations.
I would love to see a list of these 50 engineers, their skills and how they are organized. It provides guidance for other teams (even if part of their software is written in Erlang!).
For reference, Level Money sold to C1 and had 1 backend engineer, 1 android engineer, and 1 ios engineer.<p>This scale isn't unusual at all. Really it's a lot more about feature development. The smart way to build most mobile startups is to use managed providers like google app engine, AWS Container Service, or Heroku. Between that and how not-bad both Android and iOS are to develop for these days (compared to their history), it's possible to get your engineering team size pretty small.
"Enlightened Product Management" is the phrase I've heard to describe WhatsApp's success in keeping their engineering requirements to a bare minimum.
Question for HN: what is your estimate on the minimum man/womanpower needed to scale a product/service up to 10K users? 1M? 900M?
For instance, what fraction of Facebook's work is related to making things scale? How much effort does a smaller company like Quora put into scaling for users?
I imagine PaaS/IaaS services like Google App Engine and Amazon Elastic Beanstalk help a lot but I'm curious as to what you think.
Because they kept their product simple and focused, it does a few things well.<p>The Erlang thing is nice a nice fit, but mostly because they leveraged an open source product.
I think this is the key line: “The number-one lesson is just be very focused on what you need to do”.<p>My sense is that WhatsApp spends all of its energy on the very core product offering and not a bunch of superfluous activities. I don't think the language choice has much to do with it unless there's some sort of "keep it simple" thinking that the languages somehow exude.
Does anyone know if WhatsApp uses Scrum (or similar methodology)? Also, do they do pair programming?<p>My company has recently learned about scrum and pair-programming, that seems like the only way to success to them. So, it would be nice to know how other successful companies are organized and develop software.
I heard that they have the philosophy of "you build it, you own it", meaning that anything you build, you are also responsible for running. So if you don't want a call at 3am, make sure your code works correctly.
I did know WhatsApp uses Erlang which supports hot deployment. But after reading this article, I still don't know <i>Why WhatsApp Only Needs 50 Engineers for Its 900M Users</i>.
The reason why whatsapp can keep it small is because they decide features based on engineering cost first. Does the designer want a feature or UX design that would be a pain in the ass to create with this UX kit? Is there a probably uglier equivalent that would take 1/10th of the engineering time? It gets shot down and we do it the engineer-simpler way.<p>One UX example in the iphone app is the action sheet that pops up when you want to send photos or your location. While in facebook it gets embedded in a fancy keyboard drawer. The action sheet version probably took about 5 hours total for all of it, while facebook messenger's version probably took 500 hours minimum.<p>Another example on the backend is how they are relatively stateless, do not keep chat histories, do not have real multi-device w/ one account capabilities and so on. Each of those features would increase engineering and machine cost, sometimes significantly.
Our company is solving a similar large-scale problem with very few engineers. And our answer, too, is Erlang! (And also, a few very smart, highly experienced, people with Math graduate degrees.)