Why WhatsApp Was Able to Support 50B Messages a Day with 32 Engineers
newsletter.systemdesign.one
newsletter.systemdesign.one
It’s when a model spits out a seemingly reasonable text, but it’s slightly off in the context. Nothing about it is incorrect, exactly, but it can be odd if you think about it for a second.
So the title poses the question of how a product can be so robust with such a small team maintaning it. Yet one of the answers given in the article body is “having a small team”.
If you want to point out that such a team size is an asset rather than weakness, then you should work out the argument fully. This way it ends up feeling almost tautological. Yeah, obviously, if you want a small team to work on a big product, one of the ingredients of that approach is a small team…
Not saying this article is necessarily AI-generated, but there’s something almost-right about it.
Almost any system can do the same if you start from the basics of "how many bytes of data do I need to move?", and "how many bytes of data can this ethernet cable/CPU transfer each second?"
The end result is a system which is typically lower level and less flexible, but has much better money and hardware efficiency.
You'll end up delving into the Linux kernel and sockets API's, rather than using NodeJS and MongoDB. It'll take a totally different type of engineer to do so too, so make sure you hire appropriately!
Doesn't mean it's not useful in scenarios where you do require it [1]
[1] https://unetworkingab.medium.com/millions-of-active-websocke...
And yet here we are discussing WhatsApp which notably used Erlang, and I would not call BEAM particularly lightweight thing.
If you look at it, much of the problem was already solved at a fundamental level: kernel/network developers have been thinking about how to efficiently send messages since forever. Jabber devs had thought about certain problems on top of that as well.
Put those together and don't add anything, you should be able to send a huge number of messages. Keep in mind it's not latency sensitive either, people can live with getting their messages 1s or late and with significant jitter.
That's not to poop on the success of WhatsApp, I do think it's a good product. But it's a the product that enables the engineering to stay focused.
Not anymore. I'm wondering how many engineers they have now to develop and maintain all the non-chat features.
Crypto shit aside, I think Signal is way more focused. Element/Matrix, too.
> scheduled for release in the fourth quarter, is designed
> Refactoring COBOL to Java is a difficult process that can take decades and often fails. IBM expects the AI tool will speed the process by an order of magnitude.
The good news with AI is that you usually get an answer even if it is impossible. And the company which way back was taken to court for it's vaporware can now point to the AI providing a schedule which will be impossible to implement. Either that or the DEA should raid it as someone is smoking something illegal there promising 10x schedule compression.
If they can be sent and stored on the users devices, the server would only be a discovery service processing the occasional "Hey, I have a new IP" and "Hey, I want to send a message to X, please give me their current IP" messages.
If the messages would have to be processed by servers, the system could be set up similar to email servers, where each server can handle - say - 10 million users and be completely independent of the other servers. So scaling would just mean adding a new "email" server for every new 10 million users.
If 50B messages amount to - say - 500 million users, that would mean operating 50 servers.
You can't just send messages directly to end user devices' IPs unless there's no firewall or NAT in front of them. Good luck forwarding a port on a mobile device.
Yes you can, through hole punching, I used that technique in several platforms I built to establish a low latency p2p sockets for telem/msgs/and even C2 links for some drones/ugv.
Simple message apps do not require huge number of developers to support many messages.