41–50 of 462 posts
Earlier quoted context omitted.
Theres a high scalability post from years ago that has a bit more information. http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-...
>19B messages in & 40B out per day whatsapp being a closed system I don't understand how this disparity is possible.
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.
Having extremely talented engineers and a rather small scope is what allowed them to grow til 1B users, with a minimum staff. Yet people seem to focus on the technology, because that's more easily replicated, and easier to accept, in my opinion.
Earlier quoted context omitted.
Whatsapp used to charge 1 eur or usd per year per user. Assuming a 20% vat, that’s $800M in yearly revenue. If you spend $500k per engineer per year, you’re still left with $775M to handle infrastructure and all other expenses. Whatsapp would have been sustainable without fb. That’s the regret.
Facebook to WhatsApp team in the acquisition negotiations: "If you don't sell to us, we'll build our own and offer it for free" And they would have been out of business sooner or later. There are enough people wanting to save that one dollar.
Is there even a correlation between scale and engineers, other than scale = VC money = hire more cause we can afford it?
I would expect there to be certain scaling. Specially when you move to more severs and more redundancy. Cloud solves part, but still not everything. If single person can support 10k or 100k users. You might still need more than that one to move to million or hundred million. Also some features like language support and such get more complicated when you want to widen userbase from just English speaking ones.
I asked if there was a correlation here, using an if statement as an answer doesn't answer it haha. You're now asking the same question I was, just in-line
I'm not saying that it's an easy problem to solve, but it is a much easier problem to solve than a lot of other applications.
Earlier quoted context omitted.
That was its fate anyway. Some things just can't really make money unless they do it in scummy ways (or we haven't found a viable alternative or a way to protect them). Public instant messengers, public forums, public file hosting, public image hosting.
Makes me wonder just what FB will do to Whatsapp to keep the money flowing in, as FB's core app/website declines.
Plan B: ummm
"The simpler product makes it much easier to maintain and scale." This is good news for the developers, the product owners and the customers. I still can't understand why today people choose a (Javascript) stack of build systems, ton of dependencies, and all kinds of exotic tech that is the latest and most hyped. As a developer you need to support this in the future. It might be nice to build today but it will be a n…
> exotic tech that is the latest and most hyped You answered your own question. Because it's "exotic" and "hyped".
My fast reading brain with not enough caffeine read that as 'toxic'.
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.
> 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. It's something I think we have all seen a lot of times - that by the time a company is serving 1 billion users it has quickly expanded out it's engineering team hugely, and because of that additional abstraction is required and the complexity/LOC skyrockets.
But makes little sense (as a developer/engineer myself) to think that growth in users, requires a ton of new developers/engineers. We are not tattoo artists, our job can scale indefinitely if set up properly, i.e. all you should need to scale further (to 1BN or 7BN) should be enough money to buy more hardware; which WhatsApp/Facebook clearly has.
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.
Theres a high scalability post from years ago that has a bit more information. http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-...
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.
> 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. It's something I think we have all seen a lot of times - that by the time a company is serving 1 billion users it has quickly expanded out it's engineering team hugely, and because of that additional abstraction is required and the complexity/LOC skyrockets.
"this team of 4 engineers is responsible for formatting the date of a message"
"this team of 7 engineers is responsible for the overall formatting of a chat"
"this team of 5 engineers is responsible for the formatting of the non-chat pars of the application, settings, profile page"
"this team of 4 ux persons is responsible for aligning the non-technical parts of formatting and the user experience over all parts of the application"
"this crossfunctional team of 5 is responsible for creating a framework to let the configuration of formatting be disconnected from the actual implementation of the formatting"
"this team of 7 QA engineers will aid in manual verification of changes and bugfixes but will also automate test cases for formatting in the entire application"
"this supporting team of 4 will develop automation tools and enable the formatting teams to collaborate in a high speed agile context"