Designing Facebook Messenger

In video it shows kafka topic for each chatId with 500M users there can be billions of chats . with that many topics kafks will crash do we mean to partition based on chat server id?

I know the solution includes a description of the tables/schema but other solutions contain a schema. Seems like it would be more consistent if this solution was written in the same way as other solutions.

Giving an error to the user or making them re-send a message just because the recipient is offline is such a bizarre and poor user experience. Push notification merits serious consideration in the design instead of a minor footnote at the very end

Or is it that somehow they forgot to mention KGS?

Both these are not discussed in this topic I believe. Thoughts?

Why is it more important to see all the same messages on all devices vs having the service be highly available? Is it a better experience to not have access to chat and potentially have it be slow due to consensus quorum, which is in contrast w/ the low latency NFR, or have it truly be low latency and highly available and be out of date but eventually be consistent after some X time?

A modern server can handle way more than 50k open concurrent connections (websockets) for pushing messages. We don't need 10k servers for handling this.

For data partitioning, why not use consistent hashing, doing % 1000 means if its get imbalance then we need to readjust?

you say "How do we know which server holds the connection to which user? We can introduce a software load balancer in front of our chat servers; that can map each UserID to a server to redirect the request."

Lets say there are 10 thousand users , how can we configure the reverse proxy to map these users to the chat server? Would it not be cumbersome? Will not the laoad balancer need to maintain these user info anywhere?

https://www.youtube.com/watch?v=zKPNUMkwOJE&t=1511s is complimentary for messenger design, answers few un-answered questions.