System Design: Messenger service like Whatsapp or WeChat - Interview Question

designing a messaging service like whatsapp Facebook Messenger or WeChat is a popular system design question stay tuned [Music] usually one out of five or six interviews is around system design and in this case we're going to take a look at designing a messaging service like whatsapp and whereas with every interview question and as with every system design interview question those questions are super broad and don't get into the rabbit hole and start talking about just one topic in the beginning spend a couple of minutes to find out what exactly the interviewer wants to hear from you so normally they they tend to look at how well you ask questions in the beginning and then how you tackle the problem and take all the facets of this problem so in this case designing a messaging service that can range from a super simple messaging service like a chat that between those two people but you could talk about designing a messaging service with all kinds of features maybe videos maybe voice and scaling it to millions and millions of people so what kind of questions should you ask interviewer in something like this it makes total sense to ask about features first and then derive the architectures from those features so with with what said we could say we want a messaging service to be available on mobile phones and we went one-to-one messaging with just text this could be our baseline and from there on we could add features later now let's write down some of those features okay so probably the most important one we want to have messaging between two parties no group chats at the moment and just text another one could be which is really nice in something that was that what I was doing for a long time is having a sent confirmation and a delivered confirmation and a read confirmation so maybe if you use whatsapp you notice those checkmarks and the bottom of each message first one means message was sent so outgoing from your phone your device second checkmark means it was delivered to the recipient and when those two checkmarks start go from grey to blue it means the message was read so at least the recipient opened up the messaging app and saw your messaging threat and then a third feature we could talk about is push notifications so push notifications is a little bit different than this kind of stuff because all we want is a notification on the device as soon as a message comes in so we're going to talk about it later push notifications have some characteristics which differ quite a lot from the rest of this message it's a messaging stuff so one more thing before we start to of course nobody expects from you to design one of those huge applications full-fledged on the whiteboard it's only one hour so you can only touch so many subjects right still it's a good idea to have a good understanding or at least an idea of how systems like this are designed in reality and there are some very good resources out there which help you and they're also super interesting to read one of them is the high scalability block and another one is a page called tired in tech both will be linked down in the description of this video so now to the design of that first feature we want to have two parties communicating with each other with just text messages so that means we have two devices we're connected to the Internet in between there will be something like a server because what we want is even if that second party is not online we want to have messages being sent through and then when that second party comes online as soon as these online are connected to our server the message will be sent to him so very broad we have Bob and Alice so those are our two parties and they want to exchange messages so with a server in between storing messages and starting messages of those two the bottleneck will become this server in the middle so whatever we want to scale solutions like that we have to think about being asynchronous so meaning those three elements don't have to be synchronized at all times and the second thing would you think about is scaling horizontally so instead of adding compute power to this middle component here and making it making it bigger and you know adding more RAM adding more memory adding more power we are adding multiple of those components next to each other and in an ideal world it shouldn't matter to which server Alice is connecting and to which server Bob is connecting and in one conversation they should be able to connect to whatever server there is at this moment and whatever server has capacity to serve them so now you see we have three servers and you could think about sending a message to this one and as soon as Bob comes online this one will be delivered from this server so what do we need in each of those servers and what do we need as soon as one of those servers will start to serve one one of those two parties there has to be something like a queue in here right because what we want is to deliver a message to the server and then deliver it to Bob and let's say we don't want to store all the messages in the server and that's that's something you have to discuss with your interview because maybe it is a requirement to store all the messages for like a history or all the purpose in service but to optimize for storage we could say we only store in servers and what is needed at the moment and as soon as we delivered to Bob we can delete messages in the server so now let's look at one of those servers in detail so one of our servers could look like this you can have a number of queues in that server and those q themselves are also a ephemeral meaning if they if they are empty they could be released and could free up space and if those queues are mainly to store messages from a person like Alice so let's say Alice sends a message and this is Alice queue and there is one message in there and Alice wants to deliver to ball so now as soon as Bob comes along that message will get put out of the queue to Bob and the queue itself could be deleted and also the message will be because Bob already retrieved it and in reality that's exactly what what said miss doing they don't store messages for you as soon as they can deliver they will deliver and then they get rid of their of those messages in the server okay now we have a rough design of servers multiple servers being horizontally scaled and how they relate to those two parties and let's think about a characteristic you maybe have noticed in whatsapp or other messaging apps when you send a message and you are offline at this moment or maybe the other party is offline it can happen that messages get delivered in the wrong order and that's exactly what can happen with architectures like that because possibly while you sent the first message and you're Ellis you will connect to server one up here but server one couldn't deliver to Bob at this time then you send a second message and at this time because everyone was just not available for you maybe you moved and you moved out of a region or maybe that server has too much load on him and then the second time you were connected to this server and now this server has one of your messages in this queue and three servants oners of your messages in his queue and now Bob comes online and now this is like a race between those two servers because this one will try to deliver and this one will try to deliver to Bob and of course now it can happen that server two delivers first and server 1 deliver second then your messages arrived here in the wrong order okay let's move to the second feature now because we talked quite a lot about one-to-one the text messaging of course there's a lot more you could talk about like making the architecture faster and scaling it in different ways are using caches somewhere maybe using history and audit service to store message logs but let's move on to the second one so second one is a sent delivered read messages so what happens here you could imagine that when sending a message to the server the server because it's a it's a it's some sort of a connection will be something like a TCP connection the server will reply with an acknowledgement that he received the message from Ellis okay so this is an ACK this is the message and this is the ACK coming back now with the acknowledgement coming back from the server to Ellis we have this part for the sent part already done because at that moment we can put one checkmark above or below our message now the deliver checkmark it's a little bit more complicated because that's any messages in this in this server it's in that queue that you belongs to Ellis only when this server can deliver the message to Bob we have to open up a second connection or at least we have to connect to Ellis just to send the delivered checkmark so at some point in time when this server connected to both delivers that message there will be a second connection open just to send the delivered checkmark and of course again Ellis would send back an acknowledgement to let the server know that this checkmark was sent correctly okay now that's here and what about the red so the red checkmark will happen again as soon as Bob opens his phone and reads the message and he will need to send the message over a server to Ellis now you could imagine that using also for the delivered and for the red you could you could use a message instead of the same server going back you could use a special kind of message and you could queue it the same way and send it to Ellis because it doesn't matter which server tells Ellis that a certain message was delivered right so you could imagine that Bob without him typing it of course sent an acknowledgment with a message ID to a server it will be queued like a regular message so it will be queued in one of those servers and have a CK in here and it will be delivered to Ellis and it doesn't matter which server it has to be which makes which is very much what we want because we want to be agnostic of which server will be using those those servers should be should have no difference because we want to turn them down we want to be able to operate them we want to be able to hot-swap call on them and we want to add more if there's for example a spike in traffic so that's maybe not a bad idea same so same for the delivered message we could just use a special kind of message which the server creates and sends to Ellis that's it okay that's the red okay now on to push notifications push notifications if we think about them they are pretty different from text messages because push notifications and of course they have to be delivered as text messages when the recipient is online but at the same time we don't expect any interaction with those post much push messages so all as a server all we want is deliberate and getting some sort of acknowledgment that the recipient received that push notification and that person's phone showed it so in reality what whatsapp for example does is using Google's cloud messaging platform to deliver those push push notifications because of course you don't want to implement everything on your own and if somebody like Google and you're working on Android and cat from Mac Android offers something like that and chances are that you want to use it so push notification probably would be a totally different system than this one and you want to optimize it for this one purpose of sending notifications to all kinds of people so you could imagine that when a server receives a message he stores or he sends a request to another system which is only there for push notifications and this one will send out the message to the to that person's phone and to optimize this a little bit you could imagine that sending the push notification and gets delayed until that soever has capacity to do to send us this push notification to the other system because push notifications themselves they are of course somewhat time-critical but people don't expect the same accuracy as for one to one text so this is striking striking a compromise it's writing a balance between what's your first and foremost goal in this kind and in this case it's delivering the text message as soon as possible and also push notifications themselves are by nature fire-and-forget that means the server sends them and as soon as she gets the acknowledgement that the recipient received it he will that the server will delete it from his queue and never try to send it again and he probably also doesn't have to store that post push message or any record that he sent the post-match push message besides of course if a Google service like Google Cloud messaging or if the cloud messaging platform will log metrics and data about how many push push messages were sent for what purpose and to what receipt and that was feature number three and now if you still want to dive deeper into other topics of messaging services you could think about a couple of topics so one of them could be having group conversations where you have multiple recipients for for messaging so broadcasting messaging but you could also talk about just scaling more and scaling for millions and even billions of users and then topics like like maybe caching or database replication database sharding and stuff like that will be more interesting and on the topics of databases it could be worth to talk about storing messages and having a message history or message log on the server side but also it could be worth talking about having backups so client-side backups for messages something that whatsapp really offers is connecting to services like Dropbox or Google Drive or iCloud to to store backups of messages of users and finally what you could also talk about is monetization so again this is and I mention it in this other system is an interview this is maybe not something you'll be asked as a junior developer but if you're in a management role or if you are in a product management problem it's going to be mainly about how to design the product of course and monetize it and also show some technical knowledge so what set as you know is advertisement free even after Facebook bought it they were still advertisement free but you could think about stuff like Asian messengers like lion and WeChat too when they sell stickers and emojis and you could talk about usage limits and you could talk about premium services and all kinds of stuff let's not forget about things like load balancing so although we didn't draw it on this picture and between the server and the parties now there will be some sort of load balancing because the load balancer then will decide which server which messaging server will serve that customer so here and here there will be layers of load balancing and also maybe layers of caching for other services which deliver content to the customers devices ok this is today's video I gave you a quick rundown of how to design something like whatsapp or Facebook Messenger and we looked at three core features and we also talked about some of the more advanced topics and as a quick summary don't forget if you ever get asked something like this take a step back and think about the features first and then derive from those features the desired architecture and it's absolutely ok if you start with some simple features first and then grow the architecture and grow the feature list as you're progressing in the interview and the interviewer will give you a lead we'll give you some guidance on what topics he wants to hear about and just keep talking and keep asking questions if you liked today's video please give me a thumbs up subscribe to this channel my name is Ramon Lopez and this is success in tech [Music] [Music]

Channel: Success in Tech

Views: 323,699

Keywords: system design, whatsapp, interview question, how to design, messenger service, software engineering interview, developer interview, class diagram, concurrent system, asynchronous, scalability, high scalability

Id: 5m0L0k8ZtEs

Length: 21min 26sec (1286 seconds)

Published: Wed Sep 06 2017