It's missing the most important part. It's based on a mature protocol (XMPP) that is battle tested in handling extremely heavy loads.
Why WhatsApp Was Able to Support 50B Messages a Day with 32 Engineers
21–30 of 31 posts
Re: Why WhatsApp Was Able to Support 50B Messages a Day with 32 Engineers
#22Earlier quoted context omitted.
Node js is a surprisingly lightweight API layer for manipulating Linux IO
The problem is that the NodeJS ecosystem infrastructure doesn't exactly like efficient programming - you have to go pretty much bare metal to actually be lightweight.
Or maybe NodeJS is just leveraged a lot for cases where this kind of performance isn't required.
Doesn't mean it's not useful in scenarios where you do require it [1]
[1] https://unetworkingab.medium.com/millions-of-active-websocke...
Re: Why WhatsApp Was Able to Support 50B Messages a Day with 32 Engineers
#23Earlier quoted context omitted.
They are still so much better than almost anyone else in the space at preventing feature creep. It is still a remarkably small and focused app.
Is it? WhatsApp calls home a lot in background, so much it was draining my phone’s battery. Also, business features are coming for a while, bloating the app. Heck, on iOS its installer has 163 MB! Crypto shit aside, I think Signal is way more focused. Element/Matrix, too.
I know very well of 20 people atleast who use Whatsapp a lot and nobody has had an issue with battery due to Whatsapp. You can try Netguard and disable Whatsapp networking to validate your battery hypothesis, but I doubt it is true. Business features are not in the app for normal users (Whatsapp Business is a different app), and I don't even know of a single business feature. Business chats to me are like normal chats. 163 MB is below normal these days on iOS AFAIK. I think both Signal and Element have similar sizes.
Re: Why WhatsApp Was Able to Support 50B Messages a Day with 32 Engineers
#24I wonder what's the current performance delta between FreeBSD and Linux
Re: Why WhatsApp Was Able to Support 50B Messages a Day with 32 Engineers
#25It was just a system designed from the start with efficiency in mind, rather than business flexibility. 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…
Erlang is the big fly in the ointment here. It's very inefficient. In fact it makes rather ridiculous performance sacrifices in the interest of stability, and encourages you to make it even worse.
Re: Why WhatsApp Was Able to Support 50B Messages a Day with 32 Engineers
#26not a good article - all of the points are extremely cliched and/or just obvious normal practice.
This depends on your definition of good. This seems to be an article aimed at clueless decision makers to persuade them to keep them in the IBM realm. It has all the good messages like IBM got an AI tool for you. You love mainframes. You are not in a dead end where programmers are retiring faster than you can hire replacements and migration is impossible as the remaining crew can't support the additional effort for making the change.
> 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.
Re: Why WhatsApp Was Able to Support 50B Messages a Day with 32 Engineers
#27Earlier quoted context omitted.
Node js is a surprisingly lightweight API layer for manipulating Linux IO
The problem is that the NodeJS ecosystem infrastructure doesn't exactly like efficient programming - you have to go pretty much bare metal to actually be lightweight.
> you have to go pretty much bare metal to actually be lightweight
And yet here we are discussing WhatsApp which notably used Erlang, and I would not call BEAM particularly lightweight thing.
Re: Why WhatsApp Was Able to Support 50B Messages a Day with 32 Engineers
#28My first question would be if the messages can be sent P2P or if they have to be passed through / stored on servers. 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…
> 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. 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.
> You can't just send messages directly to end user devices' IPs unless there's no firewall or NAT in front of them.
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.
Re: Why WhatsApp Was Able to Support 50B Messages a Day with 32 Engineers
#29This seems like one of those listicle-style, content-free article, all markers of what is possibly a ChatGPT generated article.
Yeah, very likely AI generated. Also extremely light and any meaningful concrete details. For examples things like /single responsibility principle" or "small teams" you can just put them anywhere to pad the length
There’s something I like to call AI “almost-rightness”, although I’m sure there’s a better term for it out there. It’s a bit like linguistic uncanny valley.
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.
Re: Why WhatsApp Was Able to Support 50B Messages a Day with 32 Engineers
#30It was just a system designed from the start with efficiency in mind, rather than business flexibility. 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…
Node js is a surprisingly lightweight API layer for manipulating Linux IO
As long as you like having terribly restrictive threads....