⚠ Switch to EXCALIDRAW VIEW in the MORE OPTIONS menu of this document. ⚠ You can decompress Drawing data with the command palette: ‘Decompress current Excalidraw file’. For more info check in plugin settings under ‘Saving’
Excalidraw Data
Text Elements
commenter client
Comment management service, handles SSE connection with all connected clients
comment broad casting
cassandra dynamoDB
Improved flow with Pub Sub, separating sending comment to client from Content management service via PUB/SUB
commenter client
CMS
DB
Real Time Messaging Server Managing SSE connection and relations
Redis PUB/SUB
publish videoId/Post id and new comment
save
fetch new comments, Send new comment to connected client streaming current post/video Id
SSE
Challanges: It is not very efficient. Each Realtime Messaging Server needs to process every comment, even if it is not broadcasting that live video. This leads to inefficiency, slow performance, and high compute intensity that’s impractical at FB scale.
Improved flow with Pub Sub partitioning, separating sending comment to client from Content management service via PUB/SUB multiple channel
CMS
RTMS
partitions by live video topic per video
v1
v2
v3
v4
v5
subscribe only to topic, which contains comments on live video your connected client is watching
Redis PUB/SUB
Partition per video will cause a lots of paritions that will lead to lots of resource consumption. routing comments of multiple video to one channel can help in better resource and cpu uses. We can create N channels and determine which channel to broadcast a comment to based on hash(liveVideoId) % N.
Challanges
While this approach is more efficient, it is not perfect. With the load balancer using round robin, there’s a risk that a server could end up with viewers subscribed to many different streams, replicating the issue from the previous approach.
Ex: 3 people watching video 1, but 3 connections are created using 3 RTMS server due to round robin allocation of client connection Then all the 3 RTMS server needs to subscribe to 1 partition which is handling video 1. If there are Millions of user, this would lead to huge consumer of a partition.
ideally all client connection watching video1 should go to 1 RTMS server
Diag: 2
Diag: 3
Diag: 4
comment DB
Comment management service, handles SSE connection with all connected clients
comment broad casting
cassandra dynamoDB
SSE
commenter
comment
Basic flow with Server Sent Event
Daig: 1
SSE connection based on livevideoId
zookeeper
1
2
zookpeer responsible for sending comment to correct messaging server
Disadvantages: This has extra overhead due to extra hop as zookeeper
PUB/SUB with layer 7 load balancer
hash(videoId)%N
API Gateway
Layer 7 API gateway
commentor
layer 7 load balancer
CMS
PUB/SUB
RTMS
SSE connect based on liveVideoId
DB
Subscribe only to topic with comment on live video that your client is watching
Viewer of the video endup watching via same server box using layer 7 LB.
This leads to fewer topic to subscribe to per server
Dispatcher approach instead of PUB/SUB
In This approach, the comment creation service doesn’t need to know the destination server; it just publishes messages and the right servers pick them up. While standard and effective, this approach adds complexity in managing subscriptions and scaling read-heavy workloads.
Advantages: No pub sub topic mapping handling
RTMS
new comment
https
https
https
Diag: 5