WHATSAPP System Design: Chat Messaging Systems for Interviews

The Whatsapp system architecture is a common system design interview question. This interview question asks us to select a set of features like sending chat messages, read receipts, group messaging and last seen visibility.

The chat system must be scalable and have other non functional requirements like message ordering, retrial, idempotency, load balancing and image sharing.

Recommended system design video course:

Along with video lectures, this course has architecture diagrams, capacity planning, API contracts and evaluation tests. It's a complete package.

Use the coupon code 'earlybird' for a 20% discount!

Check out the other system design videos on the channel here:

References:

Chapters
00:00 Requirement Setting
02:35 Image storage
03:07 System Design
15:00 Load balancer
21:00 Consistent Hashing
21:55 Message Queues
23:05 Messaging idempotency and ordering

#SystemDesign #DesignWhatsapp #gkcs

You can follow me on:

[louis-ericsimard]

Hi Gaurav, I have been a developer for 43 years and a system architect for 30. As a very experienced professional all I can say is: good work ! You are the real deal.

[zippytyro]

I learn more on YouTube than school !!

[ashishchourasia]

I don't know anything about system design or even what it is, yet I clicked the video and watched it full. Just understood everything, great teaching skills :)

[varunmahanot]

occasions like good morning in India putting a lot of pressure on the servers🤣🤣

[asurakengan]

This was great. A minor nitpick, this is not what peer to peer means although it can be confusing. Peer to peer would mean apart from one time registration, the connection never touches your server and instead is established directly between 2 clients(friends on whatsapp). Also HTTP now has server push and whatsapp actually uses XMPP(slightly modified).

[mitgundigara]

I personally felt this is too abstract however it's good place to start. There are multiple scenarios which is not handled and it's assumed that it's happy case. I request to go slight deeper in each feature. The design explained in the video is "common sense", any software developer would have think of it. But I really request if you can answer some of the below questions which interviewer can ask us during the interview, if we would have explain the same.

1) You first explained we would store the mapping of each client to the gateway box. But there will be multiple clients will be connected to same gateway. let's say A is on gateway no 1 and B & C is on gateway no 2. then let's say A sends message to B. How would gateway-2 know where we need to route the message for B and C. My hunch is gateway will be storing this information.

2) I really wanted to understand when you will use Gateway vs Load Balancer. In your all videos somewhere you have used gateway and some places you used Load Balancer. You should explain why gateway over load balancer.

3) How are you maintaining the sequence of the message is not explained, this should be a very basic message. A and B can see different view of the message.

4) Why do we need message queue to store the failed message? IMO we should maintain 3 DBs. Sent, Delivered & NotDelivered with userId as key and Map<UserId/GroupId, List<Message>>. This will be easier. Whenever A sends message and chat server receives the message you can probably initiate two thread where one thread store message in NotDelivered table and the other thread calls SessionService to fetch the B's gateway box and send the message. Once B send acknowledgement then we can remove message from the NotDelivered and put in Delivered table. You can delete the message from the DB and archive the message in the low cost storage like S3 after 30 days or data is backup. Generally it happens every day night. The advantage of this is let's say B is offline then we do have store all the message that B got from all user's in B's contact list in Not Delivered table. Once B turns internet on their app will send long polling request and then can easily fetch all the data. Is this good design? I might be wrong but this is my thought.

5) You should mention what data we can cache and at which layer.

6) I think you should be more clear when your connection will be active, when it will not. I think if someone has opened whatsapp application or as long as it is there in app background stack the connection should be open. Once we remove the application from the background stack then connection will be lost. Once the connection is lost then your application will continue to send the long polling request until internet is on at certain interval. This kind of arch will have benefit of both websocket and long polling. Once internet is off it can't do even long polling.

7) What type of database and what are the data we are storing. I read in grokking system book that we can use Cassandra (wide column family) But I didn't understood why. So What I am suggesting if possible rather than making too much abstract information, make videos little more systematic it can help us. I think there are multiple counter questions interviewer can ask. why to choose this database over other. what data you would cache, which cache policy would you use (write back/around/through).

8) Here API gateway is just routing the chat server right?


It's very difficult to put all the information together. But making video more systematic would certainly help me and others. You can have define structure while making system design video.
at least following structure might help better. If you can even explain 5 mins for each of the section could be very helpful to all of us doing system design preparation.

1) Requirement
2) Define constraint/limitation/ data constraint like no of server, Incoming/outgoing data/memory storage
3) High level design for each feature
4) API Gateway/ Load Balancer
5) Data layer what data you will be storing
6) Caching
7) Sharding

[maggiemu]

I really amazed by how good you are at explaining complex concept in such a simple way. I can just keep watching all your video. Great job! ❤️

[Fmus]

Hey man, nice video, but there's a mistake: long polling is not polling every minute to get updates. Long polling is when you keep an HTTP request open (think: spinner in Chrome while the page is loading) forever, until the server decides to respond. This in effect makes it near real-time. It's one of the ways websockets work.

[GaneshAcharyaAnEngineer]

Great video, this kind of stuff is not easy to learn and not enough resources out to explain. Thank you for your great efforts

[abhijit-sarkar]

Having sat in FAANG interviews both as an interviewer and as a candidate, I can say that this is not going to hold up for someone interviewing for a senior position.If you have less than 5-7 years of experience, you may get away with some hand waving, but for 10+ years, we want to see more depth. Some of the users have already brought up questions like delivery of offline messages, which is a basic feature missing. Apart from that, there are some crucial things missing in this video:
1. **API**: You want to discuss basic API (like REST) design, verbs supported, payload etc. You don't need to spend 30 minutes creating a JSON schema, but mention the endpoints and what's being sent and received. This matters for latency, and for some advanced things like security, API versioning, bandwidth usage etc.
2. **Back of the envelope calculations**: This is important for scalability, availability and storage. How many daily active users? Is there a limit to the message size? (you probably don't want people dropping 5 GB pirated movies in a group). How many gateway servers do you need? How long are the messages stored? Do you need to shard the DB? What is your partition key, and how do you deal with hot partitions?
3. Most importantly, **offer alternative design options and discuss trade offs**. If you can only talk about one thing, then you most likely learned it from some blog/video/whatever. There's no perfect solution in system design, so, we want to know you can think out of the box, and why you are choosing to go one way or the other.

[hridayeshsharma]

12:43 Now I understand why my gf would still show online for sometime even after we have sent goodnight messages. 😂😂

[adamhughes]

interview: "ya I'd have a lst seen microservice". Reality: "ok just add that as a function in your monolith we don't have time for a new service"

[clinton]

I watched other videos on messaging systems and this video has a very detailed approach, I was hunting for videos just to know how to have multiple servers for socket processes when the client is a mobile app and I feel this video has helped me a lot with that.

[kushagrak]

YouTube recommendation, thank you so much for this gem

[abhisheknair_music]

These videos clearly shows how far away are university syllabuses from the real-world problems

[yaraye]

One thing I really like about your video is that you always tried to explain things from the client side, which makes it highly understandable for us as clients in our daily life. Thanks for your video!

[rajchoudhary]

well narrated and presented. never knew whatsapp and tinder has so much thing at backend. interesting when you ask someone for a coffee. and she accepts the coffee invitation. both are important sugar in coffee and web sockets and the micro services. lol. Hats off. truly brilliant .

[svgi]

Age and experience doesn't matter to achieve, you proved it bro

[inasuma]

i'm interviewing this week for systems design for the first time in my 6 year career. this isn't part of my job. but here i am, learning an irrelevant (to me anyway) skill to be better at tech interviews. thanks for sharing!

[ammarshareef]

Yet another great video on system design! Keep up the good work, also now I can watch in 1080p YAY!