The WhatsApp Architecture Facebook Bought For $19 Billion
highscalability.com
highscalability.com
- No registration required. Yes and Yes. do you hear Skype ? All you need is your phone number. And let's not get started on the privacy thing because the benefits outweigh the cost. See more below
- Easy to invite others. Just sends a simple SMS/text and wala, you are in.
- In countries like the US, SMS/Texting is very expensive (yes, i know...). Specifically, if you want to talk to someone international. Whatsapp solved this problem with ease. There were others (viber etc) but they just don't have the easy interface at least in my experience. Sure, the caveat is that everyone needs to have wifi/data plans but those are getting much more easier than convincing your phone company to stop charging bullshit rates for a simple text.
- Lets you create Groups. This sounds simple but imagine wanting to talk to your core family members in 1 text ? Whatsapp lets you do that with no pain.
- Share pictures/multimedia within groups. Again, very simple to use and comes included. I don't want to even explain what these cell phone companies charge for something they lable as MMS (not text).
Overall, when I came across Whatsapp, I was like "Finally, someone gets it and this should have been so duhhh but apparently, it wasn't". Very happy for the entire whatsapp team.
"""Just sends a simple SMS/text and I promise by God, you are in."""
http://en.wikipedia.org/wiki/Wallah_(Arabic)
He didn't mean that of course...
I was confused for a moment before I thought of "voila".
That is the #1 feature for my family. I'm in the US, my sister is in India, and our parents travel all over the world. Nearly every day, we post something to our group chat. Be it photos, personal news updates, or questions to one another, we actively use it almost daily. I have an iPhone and I think they have Androids.
Siblings in England, USA and Australia and we all use the group chat.
and then
"In countries like the US, SMS/Texting is very expensive...Whatsapp solved this problem"
You need texting (a X dollar/month service) to use the service ... which solves the problem of... expensive texting?
I always found that to be somewhat odd, using a service you're trying to replace/compete with as the sole authenticating factor.
Edit: I realized after actually using the app, they do in fact offer an alternative authentication method (call). You have to try (and fail) at the texting method first.
Also, in response to derefr (I deleted my ignorant parent comment), I block texting as even if you don't pay for a plan, you still get random spam texts that you must page for (even if you didn't ask for them)
Deleted comment
Yes. Because texting in most countries has limits (e.g 200 sms per month, for more you pay an amount per text) while you can use WhatsApp for as many texts as you like.
And texting includes MMS (texting with images, sound etc), which is free in WhatsApp, but costs extra in most countries (can even go like $1 per text or more).
Also, even in the US, a combo voice+text plan with heavy texting is still going to be cheaper for a combo voice+data plan, so average user ends up paying more money, not less.
http://mobithinking.com/mobile-marketing-tools/latest-mobile...
In countries like Indonesia where SMS is almost free, they still use Whatsapp because of the Network effect.
Groups is the biggest one. It helps SELLING. YES, call it e-Commerce 3.0! This is how HOUSEWIVES sell stuffs. Through Whatsapp OR BBM.
Can you please elaborate on this.. How does it work? Any links?
Something similar to this: http://storify.com/cbccommunity/kuwait-entrepreneurs-use-ins...
In the old days, you sent SMSes but you can't spam multiple people at once. You can only send one SMS at a time (unless you program something, which Housewives don't do...)
BBM supports Groups already but it's kind of slow (at least the old BBM anyway). I don't know if WhatsApp is any faster or whether WhatsApp has any limit on how many Groups member you can have (because it is essentially almost like Twitter).
50 is a good number of people, especially if you're doing sample sales i.e. 1pm - 4pm special sales in a secret location by XX designer. For instance you can whatsapp a group of well-known fashion bloggers, who may forward the invite to a group of friends etc etc creating a semi-exclusive shopping experience
I've seen people do it for yard sales too (what we call void deck sales) It's a bit like a tupperware party.
isn't that why facebook wanted WhatsApp, as they see this is a future of mobile phones?
Really? Because I would trust their claims all the more; they've been in the trenches, they had expertise in other languages (from the article, "Having built a high performance messaging bus in C++ while at Yahoo, Rick Reed is not new to the world of high scalability architectures."), and then they became -intimate- with the language, in removing bottlenecks to their specific use case...and they still make the claim Erlang is great in this domain. Whose opinion are you going to credit more than theirs?
(Also, I bet many of the patches they made that weren't specific to their use cases were submitted as patches to the BEAM)
That's fine, but people do tend to oversell Erlang IMO. The types of things Rick Reed talks about in his talk are standard issue stuff. Lock contention? Okay, how about using an architecture that doesn't require locks in the first place?
With Erlang, you're forced into the Erlang way from day one, and it'll be tough to escape. The good news is that Erlang has a good design overall, so as long as you can modify the engine under the hood, you'll be fine.
I don't think anyone should be scared away from Erlang, just be aware what you're getting into—like any other tech you could deploy.
Also remember this is just one visible project. Erlang VM is being developed actively and many other companies and people are contributing. For an almost 30 year old language it very active. Maps are coming in R17 so are dirty schedulers, {active,N} on sockets, lots of goodies.
This was more my being agog at the author viewing the work that was done to the BEAM as evidence -against- Erlang being great, rather than the fact that these people with that level of experience stayed with it, and still raved about it, as evidence in Erlang's favor. And that the issues they encountered are probably fixed any way, or apply only to their use case (and so may still exist, but have a tradeoff that is worth keeping in other use cases).
Dealing with NIF threads just feels dirty
Edit: When you learn Erlang you'll notice every design decision was made for performance or reliability (vs making the language "nice", think Ruby). I appreciate that.
When I hear that other languages (e.g. Go) have "actors like Erlang", I have to laugh. Unless you're willing to eat all the disadvantages and performance losses that come with Erlang's approach, you don't really have "actors like Erlang"; you just have green threads.
Actor concurrency paradigm has been copies by other languages and libraries. Not many managed to copy the fault tolerance and transparent distribution aspect. Granted there are other ways to solve that (OS processes, VMs) but still, it is interesting to learn from and think about.
Not that it's not a lot of work, but isn't most of it just hard work engineering? Add hardware, deal with bottlenecks. Versus having to come up with some novel new datastructures and inter-server communications?
SMTP sends a ton of messages, too. I don't see why an IM system couldn't take essentially the same concept, where one small cluster of services is responsible for the mailboxes for certain individuals.
One can sort of take a high level look at a large class of system and just say "it sends messages from one part to another". A financial transaction sends one message from one account to another one. A lot of sites and businesses are "just" get data from database send to web page, then send updates back to the database. Pretty simple.
The devil is in the details and in the proof of work. If it is simple, ok, do it. Not being facetious, you might actually succeed. Just try it. Erlang is a good choice for it, start with that.
Hint's in the name: instant messaging. For the most part, nobody stops using SMTP if it takes 2 minutes to deliver an e-mail
Well, I don't think anybody would stop using IM too, if it took say 10 or 20 seconds to deliver an IM.
The earliest version I remember, before 98a, had a history button that would show the running log on the top of the message box window, which was nice.
The nicest thing about ICQ for me back then was the fact that the message disappeared when you sent it -- it wasn't there filling your taskbar or occupying your mindspace.
Anyone looked at what WhatsApp sends over the wire these days? I wonder what it is? A binary protocol?
So in a way, it's easier to learn FreeBSD than Linux (Server) distros.
(Full disclosure: I am a former Twilio employee.)
Tthe linkage of phone number and identity seems to be the main reason why there are no tablet versions of the whatsapp client. I wonder how satisfied whatsapp/facebook are with this constraint, and whether they intent to address it? It is possible to imagine workarounds for devices that don't have a phone number, but they don't seem as friction-free as the current identity system.
http://www.erlang-factory.com/upload/presentations/31/Eugene...
I doubt they'll have any trouble at all integrating.
This, then, is basically recreating the same problem they had before, just with 40 or so more engineers who are on the "Erlang" side of the vote.
edit: Just found out Yariv left. Still, Facebook was using ejabberd, and WhatsApp built their business around ejabberd.
They invented Thrift, I think they'll figure it out.
>By the end of this year, 6% of the global population will own a tablet, 20% will own PCs, and 22% will own smartphones.
http://www.businessinsider.com/smartphone-and-tablet-penetra...
Web allows us to create one app and with tiniest of modifications that app could be available on all of the major platforms. Don't you think this is by far better future than multitude of various platforms and versions of those platforms (see WP, Android) when you'll need a team of developers just to finish multiple versions of your app?
People use HTTP because it's what they know, not because it's technically a good (efficient, reliable, scalable) approach for their particular use case.
It does make sense for apps that also have a web component, but that's becoming less and less necessary. When you can drop it, the possibilities are pretty amazing having a fully-capable computer with CPU equivalent to a 2010 Macbook Air at your disposal at the edge of the network.
Hell, my latest project doesn't even use DNS.
I had to fight more than once against management in order not to use HTTP for everything. HTTP isn't even that simple to deal with. Good thing is that the numbers were always with me, and with code examples, it was always doable, but it's incredible how HTTP got its way in people's minds!
Have been reasonably proud of scaling my own micro (in comparison) service. But right now feel very small and humbled.
edit: minor
I think hot swapping code is a major factor in being able to quickly fix and develop a system like this.
I wonder how far one can go on another tech stack.
For example Akka is supposed to be able to handle up to 50m messages on a single box and there is some support for hot swapping in the Oracle and IBM runtime.