My wild guess is that either the stack is not really optimal (last I heard it was java) or they do other costly things at scale (sgx?)
Every actual Java project: “oh, did you want that memory and those cycles for something else? Yeah, sorry, I need them all. Why no, I’m not actually doing anything right now, why do you ask?”
Increasing the Java heap size just makes it so that when garbage collection eventually hits, it causes an even more massive slowdown across the entire application.
Many startups move up to the jam when there is little else that has optimized performance and efficiency like the jvm for 20-30 years.
Of courses this is a moot conversation if you’ve never used Java at scale. Apple and others are Java houses.
Sending mass email is still difficult. Its probably easier to pay a provider than set up and establish reputation for yourself. But they don't charge near the rates. Last time I compared rates it was something like 10x-100x to send an sms compared to an email, but it has been a while.
You can push Java very far.
Of course you can also write horribly ugly code in it.
I worked on an automated SMS marketing system back in the day so I have seen this in action, at scale. This would be stuff like "text LAKERS to 12345 for Lakers updates"- we didn't handle the Lakers but we did handle many sports teams. Though I wasn't privvy to the financial side, I got the sense that the per-text cost ended up being manageable at scale, but this is because we were one organization who would apply the rules onto our own customers, and if we failed to do so properly we risked losing the interconnects to the various carriers. We typically used a single contracted "aggregator" service which provided a unified API for the carriers. When I left, we were using OpenMarket.
When you have a self-service SaaS offering such as Twilio, the per-text costs are going to go up because the barriers for sending unwanted texts (or fail to follow the rest of the rules mandated by the TCPA) is so much lower, and Twilio has to address that organizationally which adds cost.
Additionally, Twilio does not purchase short codes (ie 12345) which means its harder for the carriers to track bad behavior across their network. There is an initial cost (fairly high) to acquiring a short code, though you can also share short codes across customers in some cases. Acquiring a single short code and sending all messages from that short code would likely reduce costs.
I would love to see more detail from Signal about what sort of SMS interconnection they are using, because directly connecting with an aggregator instead of a SaaS offering (if they haven't already) could save a lot of money, and they are definitely at the scale that would allow for it. And given that they only use it for account verification and are a non-profit, it seems likely they could get a good deal since the risk of TCPA violations is effectively zero.
I supported a marketing platform for a while, and it was so much easier to send an email than an sms.
I was on the support side, so I just saw when it went wrong, which was a lot.
Twilio offers short codes, but short codes are country specific, and the costs for sending to the US are low anyway < ~ $0.01/message for most services, lower with volume; IIRC, short code messaging costs were half, but then you've got some overseas destinations where it's $0.10/message and that's real money.
And you'll need to maintain ingress numbers in all the countries you support, and maybe numbers per carrier, depending, and you'll need to tell the user the right number to text to ... it's a lot, and it might not work well or might not save much money.
But the secret of JVM existing as an option is eventually learned by most who scale.