Designing live comment in a system design interview

Photo by Harry Cunningham on Unsplash

In this article, we will be talking about how to implement a live comment system. To understand how to answer this problem, we have to understand a few things:

• what are the functional requirements?
• what is the size/scope of the problem?
• what are the approaches that we have to take for the problem?

Let’s talk about the functional requirements. With this kind of problem, it is generally expected to function in a few manners:

• multiple users should be able view multiple live broadcasts simultaneously while not expecting too much of a delay.
• different users should be able to comment freely and see other people’s comments quickly if others comment.

How about the scope of the problem:

• we don’t really need to worry about load balancer in particular. Not that it is not essential but it will be assumed that it is handled behind the scene.
• essential question: how do we balance out between latency and performance?

How about the approaches for the problem:

• push based architecture: All the subscribers/clients listen to the server. Multiple clients are feed messages/updates to the server and the server is responsible for sending the update over to the other clients.
• pull based architecture: also known as polling, is where client periodically calls the server APIs to request for messages. The server does not handle any responsibility to relay the messages to all the clients that need it.

Hmm…let’s talk about different push solutions:

• Each live comment event can be a host. Multiple viewers can connect to the live comment event as well as other events. One issue with this approach is that if each host is connected to multiple events at the same time, it can overburden the browser and crash it. One possible solution for this issue is temporarily stop the connection between viewer and the event if it becomes inactive or idle.
• We can shard on a channel box id. Each channel box id can be connect to as many as one live comment event or as many as possible.
• Similar approach to #2 and we shard everything on a channel id. Instead of the channel box storing information about the subscriptions and which channel to subscribe to, all these channel ids are connected to the storage. If there is someone watching a live comment event, the storage needs to be updated. If a live comment event finished and ended its live, then the storage needs to be updated. This can lead to heavy amount of writing to the storage. We can solve this issue by dividing the storage into regions. When a write occurs, write to the specific region it belongs to. When a read occurs, make request to different servers and merge the data together.

What about the pull solutions?

• If the client applications try to pull comments from the system constantly, the system will crash if there are over 1 million requests. If clients delay the pull to avoid crashing the system, the user experience will be delayed and possibly not ideal. A workaround is if the server can handle a given amount of requests, we stick to a push based solution. If the server is overwhelmed, we switch to polling instead.