Video of talk http://vimeo.com/44312354

Given the same problem, I'd look at a reactor pattern MQTT mosquitto like pubsub protocol in Go, Erlang or something JVM/CLR. The beauty of publish subscribe of many low bandwidth clients is that they need tiny bits low latency work in a sizable bandwidth app. Could run BINC/CBOR RFC 7409 over zeromq on lower-end infiniband between boxen. Millions of IM users are just similar enough to tons of smart meters that the solution overlap is enough, but obviously people are more bursty with jagged sinewave daily traffic loads.

Let the clients handle end-to-end encryption with something zk DH/OTR/SMP.

I'm curious how they later monitored this and did other common SRE stuff. Also deployments.

Truly impressive scaling and efficiency. This presentation is two years old. I'd love to hear how far they've come since. My limited experience dealing with many many orders of magnitude fewer users has found the same thing this presentation stresses, though: today's hardware is outrageously fast and powerful. The slowdowns are all contention contention contention.

An interesting historical note is that Facebook's chat system was originally written in Erlang (https://www.facebook.com/note.php?note_id=14218138919), before being replaced with a C++/Java system.

From http://sequoiacapital.tumblr.com/post/77211282835/four-numbe...

32. Even by the standards of the world’s best technology companies, WhatsApp runs lean. With only 32 engineers, one WhatsApp developer supports 14 million active users, a ratio unheard of in the industry. (WhatsApp’s support team is even smaller.) This L E G E N D A R Y crew has built a reliable, low-latency service that processes 50 billion messages every day across seven platforms using Erlang, an unusual but particularly well-suited choice. All that, while maintaining greater than 99.9% uptime, so users can rely on WhatsApp the way they depend on a dial-tone.

Would something like golang even need lock-counting like BEAM ? I think the idiomatic way to work with golang is goroutines rather than mutex, etc. However, I'm not sure if any goroutine mailbox profiling tools are available.

571k pkts/s is pretty respectable, probably nearing or at the bandwidth limits of their network interface. but i'd like to know how many new connections per second can they do (avg), and how long does it take to reach 2.8M connections? (if it takes a long time to open a connection, it could take a while to establish all those open connections, and a reset of all conns could create a long wait for new users to connect)

Could similar scaling be achieved with Scala & Akka or did I just make Erlang devs snicker.

If you want evidence that HN has a fetish for money, it's that the technical details of Whatsapp's success are only closely inspected now that gratuitous cash has been thrown around.

You may view this comment as too cynical for this particular topic, but the ridiculous surge in Whatsapp stories doesn't lie. And of course we should inspect the action of successful companies.

I am merely pointing at the crude vulgarity of the Valley's barometer for success.