My guess is they're doing both.
Anecdote time. I worked at a company where one project was over-provisioned on dedicated hardware and another auto-scaled in the cloud. The over-provisioned project was much cheaper, had significantly better response times and was easier to manage. It was load tested to handle over an order of magnitude more traffic than the all-time-peak and even though fully over-provisioned, it was cheaper than the baseline usage (and slower, and harder to manage) cloud solution.
We did two games, one over-provisioned on metal, the other on auto-scaled cloud based infra.
The cost is significantly higher. We ended up with a hybrid to control for cost. But our needs are long-lived sessions which does not fit the elasticity of the cloud model well.
I wouldn’t be surprised if on NYE services like chat take priority and get extra resources from background jobs that can wait a few hours.
Offtopic- I hate those features to begin with, but I know I'm the product not the customer, and those features are to keep people on the app.
FYI, I don't think that is possible in Slack. You can choose to hide typing indicators in your view, but AFAICT you can't prevent other people from seeing when YOU are typing: https://twitter.com/SlackHQ/status/1057288342671368194
I had a 3rd party client (aMSN) that would popup a chat window as soon as someone would start typing an initial message to me. I would say "Hi" to them first and they would thing it was a big coincidence that they were trying to talk to me at the same time.
> Hi
(waiting) (waiting) (waiting)
< OK Hi
(typing) (pause) (typing) (pause) (typing) (pause) (typing) (pause)
FFS hurry up already
To me, "seen" is a feedback mechanism. When I send a message to you, I don't always need a response, but I do usually want to know that you saw the message -- sort of an ACK.
Messenger is (also) a finance system. You can send money via Messenger. You can purchase products directly in Messenger. It's had all that for more than two years now.
One thing I am curious about: how does it compare to how the old postal systems used to handle Christmas and new year loads?
On a lighter note: perhaps you can predictively generate and cache messages at the receiver's end based on their contacts and their style of communication. When a sender actually sends a message, just send one bit across, and the local cache gets flushed and displayed :)
I'm reasonably sure that UUCP + things like INN were "batching messages per destination" for efficiency a long time ago. Nowhere near the same scale, obviously, but the same kind of concept, no?
The raw numbers (users, bandwidth, latency) would be quite different.
Even by reducing a message content to close to 0 bits, I doubt you would get that much gains. Most common messages would probably be things like "lol" or an emoji, which in utf-8 is 24 to 32 bits.
But There'll always be metadata associated with each message: message id, sender, receiver, timestamps, etc. which are unremovable. If those first 3 are typical GUIDs, this is already 3*128 bits. This will put a minimum on the entire message size , and more importantly the processing time to simply route the messages is what is costly in terms of CPU time. Then there's the different receipts mentioned in the article, adding a lot more traffic.
/edit: been informed by some of the people in the picture that technically there are 2 teams there: Messenger Infra and Messenger Foundation
1 billion 100 Byte messages sums up to an almost trivial 100GB. This might be a technical challenge for the neighborhood's web admin but not for any real company.
https://www.facebook.com/notes/facebook-engineering/chat-sta...
