Whatsapp System Design | Chat Messaging Systems Design - System Design Interview Question

The Whatsapp system design is a common system design interview question. This interview question deals with a set of features like sending chat messages, read receipts, group messaging and last seen visibility.
00:00 - Introduction
01:00 - Functional Requirements of Whatsapp System Design
03:15 - Non-Functional Requirements Whatsapp System Design
04:30 - APIs Specs
10:05 - High-level System Architecture of Whatsapp Service
10:55 - Design of Routing Service
11:40 - Design of User and User Registration Services
14:15 - Design of Group Service
17:50 - Design of Chat Session Service
24:40 - Design of Fanout Service
30:35 - Design of Push Notification Service
36:50 - Final Remarks
Distributed System Design Interviews Bible | Best online resource for System Design Interview Preparation is now online. Please visit: www.thinksoftwarelearning.com?
Please follow me on / think.software.community if you like to get notified about new course chapters getting added or when we will start another round of mock interviews and you want to participate in mock interviews or any other updates. I will also take your suggestions there about the course and the channel.
Please check my other videos for more information about following topics:
1. How to generate a unique id: • System Design Intervie...
2. Distributed Cache Design: • Distributed Cache Syst...
3. The right way to tackle the system design interviews: • The Format of Distribu...
Check out our following articles:
- How to Ace Object-Oriented Design Interviews: / how-to-ace-object-orie...
- Elevator System Design - A tricky technical interview question: / elevator-system-design...
- System Design of URL Shortening Service like TinyURL: / tinyurl-design-from-th...
- File Sharing Service Like Dropbox Or Google Drive - How To Tackle System Design Interview: / how-to-tackle-system-d...
- Design Twitter - Microservices Architecture of Twitter Service: / design-twitter-microse...
- How to Effectively Use Mock Interviews to Prepare for FAANG Software Engineering Interviews: / how-to-effectively-use...
- Payment Gateway System Design - How does the Stripe work: / payment-gateway-system...
- Selecting the best database for your service: / selecting-the-best-dat...
#SystemDesign #DistributedSystems #FAANG #Facebook #Google #Amazon #Apple #Microsoft #Uber #Netflix #Oracle #Lyft #Interview #ComputerProgramming

Пікірлер: 160

  • @ThinkSoftware
    @ThinkSoftware4 жыл бұрын

    Please let me know in the comments below if you find my video useful. And please do like the video if you find it helpful. Thanks

  • @anthonydushaj3844
    @anthonydushaj38442 жыл бұрын

    One of the best System Design Content Channels on KZread, thanks for the content.

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    Thanks for the comment 🙂

  • @pegleggreglegpeg
    @pegleggreglegpeg3 жыл бұрын

    Awesome information this really helped me prepare and feel more confident about answering design questions. Even as an experienced engineer, I learned much from your videos.

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment 🙂

  • @snehasrivastava8720
    @snehasrivastava87202 жыл бұрын

    Thank you so much for the amazing content you share, the way you explain the concepts are so crisp and clear. I am preparing for my Design interviews and bumped to your videos and I am just glued here. Its a one stop shop for all the amazing System Design tips and tricks. Waiting for more these kind of videos !!

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    Thanks for the comment :)

  • @mdsadiqaligaur8557
    @mdsadiqaligaur85573 жыл бұрын

    Great explanation. Thank you!!!

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks

  • @tarun29061990
    @tarun290619903 жыл бұрын

    Informative video. Have some feedback about this 1. Discuss the protocol of the communication whether it will be http or websockets as whatsapp needs constant connection so I think websockets are the way to go. 2. Discuss more about the message lifecycle viz send, delivered, read, etc. 3. Discuss more on HLD , You can rename routing service as Gateway and Please share the approaches on choosing the right gateway for the system.

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment 🙂. These things are discussed in more detail in the course.

  • @sonykumari7793
    @sonykumari77933 жыл бұрын

    Great explanation. Thank you for such informative video.

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment 🙂

  • @tusharsinha94
    @tusharsinha943 жыл бұрын

    Apart from being a good system designer, you are a good KZreadr as well!

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment 🙂

  • @garykim313
    @garykim313 Жыл бұрын

    Commenting here because the content is amazing! Already subscribed, but more people need to watch and like this video so we can get better videos more often.

  • @ThinkSoftware

    @ThinkSoftware

    Жыл бұрын

    Thanks for the comment 😊

  • @Mohamed-uf5jh
    @Mohamed-uf5jh2 жыл бұрын

    Great Job !

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    Thanks

  • @sreddy8141
    @sreddy81412 жыл бұрын

    Thanks a lot for this wonderful explanation sir, great work, pls do more videos on design

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    Thanks for the comment 🙂

  • @kinofstars
    @kinofstars3 күн бұрын

    This is great content. Thanks!

  • @ueeabhishekkrsahu
    @ueeabhishekkrsahu3 жыл бұрын

    thank you for this great content

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment 🙂

  • @NehaGupta-lf1sr
    @NehaGupta-lf1sr3 жыл бұрын

    Thanks a lot for such an informative video

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment 🙂

  • @N3vDawg
    @N3vDawg2 жыл бұрын

    Interesting, I feel like consistency is a much more important non-functional requirement than availability. We can deal with not having a message show immediately, but if messages are delivered out of order this can lead to confusion in discussions between users.

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    This design already deals with out of order events. There is still a difference between having eventual Consistency vs out of order events, though.

  • @KapilSharma-zv5oo
    @KapilSharma-zv5oo2 жыл бұрын

    Thanks for the video. DOn't you think the Routing Service is doing too many things in this architecture ?

  • @xitlaltepec
    @xitlaltepec4 жыл бұрын

    To answer question on UserID vs GroupID in partitioning the Group service database: it seems to me that creating groups and updating their membership is potentially less frequent than the ongoing msgs posted into the group chats by users. So the Session and Fanout service benefits more from a global index on GroupID. Users who create/update a group will necessarily have to wait for scatter/gather across partitions but this is less frequent than the msg posts occurring within the group chats.

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    Thanks for the comment :). Also please let me know how do you find my videos and have you check other videos? Thanks.

  • @rishikeshpatil436
    @rishikeshpatil4363 жыл бұрын

    Great explanation, very helpful, highly recommended to all tech-savvy. I have one doubt, does WhatsApp use the database to persist chat? or its only to persist group details, individual user details, and session?

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment. It persist all chat messages.

  • @xitlaltepec
    @xitlaltepec4 жыл бұрын

    One way to ensure unique time stamps is to use a starting epoch nanosecond time stamp counter that gets set when the app server starts and increment this counter for each chat msg by one. On one instance assuming synchronized access to this counter. I’m addition, each app server can replace the top 3 bytes (which won’t change in a 2 month period) to a unique value in the 3 bytes (perhaps negotiated ahead of time using a gossip protocol between the app servers on startup). Then when one app server generates a Session ID, using epoch nanoseconds there is no collision between chats posted (almost) at the same time within a session on the chat server or between chat servers. Even a pseudo random 3 bytes number might be sufficient to prevent duplicates. In this sense it’s not a timestamp but a unique chat msg Sub ID. But because it always increments from a starting timestamp which is offset within a range of times gaps (the nanosecond side always present), it is also an increasing ID.

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    What do you think is there a possibility of duplicate records in case a burst of messages come for a group chat session and at the same time the server gets restarted? Or it would be fine? Also if you use the top 3 bytes for a server id then wouldn't it will change the ordering of the messages belonging to same group that goes to two different servers at the same time?

  • @xitlaltepec

    @xitlaltepec

    4 жыл бұрын

    For the first question, the idea from your video was that timestamp might not be unique in a burst of msgs within a session, so we could have dupes. But if a server has monotonically increasing IDs from a starting ID (epoch nanoseconds at start up is always a unique starting ID) then it will be impossible for there to be collisions based on one server. That leaves only the case where 2 servers somehow overlap closely enough at startup to share or overlap their starting IDs. To avoid this problem we just need to ensure each server has a unique offset from epoch nanoseconds. A server ID provides this. 2 bytes might be too few at scale. 3 bytes should be sufficient.

  • @ibrahimshaikh3642
    @ibrahimshaikh36423 жыл бұрын

    Very good explanation. Liked video. Could you make video on basic components or some common service for system design like Sharding, Caching, load balancer etc . Which helps understand systems design easily.

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Will do soon. Thanks for the comment 🙂

  • @harrylin6282
    @harrylin62823 жыл бұрын

    Hi, for the fanout service in this design, do we need to use the same architecture as the fanout service for twitter design (the twitter fanout service is using two set of queues), do we also need to use two set of queues to fanout in here?

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    What do you think?

  • @leroypalmer9226
    @leroypalmer92263 жыл бұрын

    This video is top notch!. Thanks a mil! Can we say that these microservices themselves are components? ie they can be represented in a component diagram?

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment. When discussing architecture of a distributed system, it is always better to talk in terms of Microservices.

  • @apcat05
    @apcat05 Жыл бұрын

    Isn't it expensive to do transactional commits for every message? Is there a in-memory / streaming based solution that can be used to improve message performance? Messages can be asynchronously persisted for long term storage.

  • @ishtmeetsahni8423
    @ishtmeetsahni84232 жыл бұрын

    Thanks for the amazing video, one thing I am not able to understand, how will the client get the session ids in case the application loosed its local data i.e. someone deletes the application and reinstalls it? I understand in Whatsapp older messages are not available on reinstall, are we saying that you can have a session and corresponding session id as long as the session id is available on the device? Thanks

  • @reactnativeandexpo
    @reactnativeandexpo4 жыл бұрын

    Seen as soon as i got notification. Awesome stuff. One doubt Where we will maintain which user is connected to which box (persistent WebSocket connection) ? Distributed cache in routing service ? as was shown in uber system design video.

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    Yes in routing service as discussed in Uber system design video. Thanks for the comment.

  • @yashgupta-dw7sn
    @yashgupta-dw7sn2 жыл бұрын

    Can you make a little long video to explain everything. The video was awesome but missing many things

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    thanks for the comment. Please do comment your questions as it will give me more ideas about future videos to make.

  • @talivanov93
    @talivanov934 жыл бұрын

    Great idea about combining users' id to create sessions Id. I guess this will be helpful for sharding. But how do we create sessionId based on group sessions? I guess that people are entering and exiting from the group all the time. Moreover, you save the status of when a message seen in the same table as the message themselves. I guess the msg column is useless because you can conclude it from the type. So you can store null there. However, there will be a lot of nulls in this raw = waste of disk space = worse performance in the long run. Maybe it would be better to save it in another table. When user 3 is logged in (29:50), it wouldn't be better just to query all the relevant messages from the DB or from cache instead of returning the messages based on the last message Id which was seen?

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    Thanks for the comment. For the group sessions, the group id will be generated as a random id. Also why the status message is also stored in the same table because it avoids querying multiple tables and also the data field will not be null. For status message the data field will contain information about the message for which the status message is sent (like message id, status like delivered/seen etc.) Message id is used as a scan key to return all the records that are newer than the last seen message id. It will be better than querying and returning all the records from from the message table for that session.

  • @gurmeetchawla8362
    @gurmeetchawla83622 жыл бұрын

    How are saying session service is stateless, as I can see you are using a cache as well as datastore for it, even though it is shared with other instances of the session service. Could you please clarify?.

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    The app servers are stateless which means the app server can crash, reboot or you can bring up new app servers without affecting the functionality of the service.

  • @bhanumar
    @bhanumar2 жыл бұрын

    For offline users last sync time(max timestamp of message) should be stored in the user app , that is user device's local memory. sync request should be initiated from individual users' devices to the routing service which should deliver all messages..

  • @ve2941
    @ve29413 жыл бұрын

    One Question: you mentioned the routing service to route messages to receipient, how does that work? For example fanout service sends messages to 3 receipients, how does the messages reach to them? If clients are connected through web sockets and since these 3 of the web sockets are hosted in different app servers of routing service how does the message from fanout service is received to these 3 different servers of routing service? Is this a topic is maintained for different sessions and these servers listen to based on what client web sockets its hosting?

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Fanout service sends messages to dispatch servers in routing service which then forward them to right server holding the connection

  • @ve2941

    @ve2941

    3 жыл бұрын

    @@ThinkSoftware how does dispatch servers receive messages? Is it queue or direct connection? And also from dispatch servers to right server what is the communication?

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    This is discussed in the course 🙂

  • @ve2941

    @ve2941

    3 жыл бұрын

    ​@@ThinkSoftware i don't see anywhere you mentioned how the message from fanout service to routing service are delivered? i went back and saw the video again. I only see push notification dealing with iOS and android but that doesn't answer my question. Because the right instance of push notification server aka dispatch server needs to get the message, which is my earlier question.

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    It is in the design of routing service in Uber system design chapter in the course. Also you can initiate a discussion inside the course as well.

  • @iamavinashdaipule
    @iamavinashdaipule3 жыл бұрын

    Thanks for the amazing video. What happens when a user is offline(phone is switched off) does the Push notification service keep retrying ?

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    No as in order to send push notification to the phone it requires a connection to the phone. The push notification service in Twitter will push the notification to APNs etc.

  • @uniquekatnoria5380
    @uniquekatnoria5380 Жыл бұрын

    Very good content and very well explained!!! Though I am not an acoustic expert, I feel your microphone is a bit closer to your mouth than I should be, and hence some unnecessary noises come from time to time. Maybe you can try to play around with different position for mic.

  • @ThinkSoftware

    @ThinkSoftware

    Жыл бұрын

    Thanks for the comment. I am still learning to create and edit videos :)

  • @shubhamqweasd
    @shubhamqweasd4 жыл бұрын

    Hey, Great content ... To generate a unique timestamp, you suggested to increment the counter coulmn in transactions.. by doing this only 1 Tx will succeed and other will Throw/Conflict. Can we do a select_for_update or row_level_locks to increment the counter column ? By doing that we ensure that all the Tx will be serialized, and as the upper bound is 256 Tx/second, I think locking can actually be practical here... Please share your thoughts on this.

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    Thanks for the comment. Yes, we can do that as well if the underlying database supports this and only lock the single record instead of entire table and the number of parallel writes per session per second is less. These are all different mechanism you should discuss with the interviewer along with the pros and cons. That will positively affect your interview performance. Also please do like the video, if you find it useful. It helps the channel. Thanks.

  • @shubhamqweasd

    @shubhamqweasd

    4 жыл бұрын

    @@ThinkSoftware Video is to the point and extremely useful... I would however recommend and request you to make a few videos focusing on LLD/OOD, in which you can cover details like design patterns, design efficiency in terms of data and time.. etc.. These LLD/OOD video are not very common on KZread and very few people get them right. I believe sharing your industry experience through these videos is a great opportunity for the viewers to learn from you.

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    Thanks for the comment. Will look into it. BTW my next video is coming soon on designing parking lot systems.

  • @nishantingle1438
    @nishantingle1438 Жыл бұрын

    5:10 if userId is phone number then it will be difficult to change phone number for an account

  • @rahulsharma5030
    @rahulsharma50303 жыл бұрын

    i landed here from uber mock interview. Can you tell me how the TCP connection is managed with client and Routing service? There should be a load balancer in front or not? I assume routing service will be distributed in nature, now how does client knows which machine to connect? If there is a load balancer between client and routing server, then how can load balancer forwards tcp connection request from client to another machine?I dont think it is possible. Other case is client directly establish with routing service, now how does client know which routing service box to hit?Can you clarify please?

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Please check Uber system design video for this.

  • @MV-qm7rs
    @MV-qm7rs4 жыл бұрын

    @17.08 the Local Index will just contain One entry in each partition based on the Group_Membership schema chosen here. Correct?

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    No it will contain multiple entries, one for each user in the group. But then all the membership entries for all the members in a group will be in the same partition.

  • @nishadpathoor
    @nishadpathoor4 жыл бұрын

    Just thought of whatsapp and start searching in google.. and found this video uploaded 5 min ago.. surprised 😱

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    I didn't know google search engine get updates so fast :)

  • @nishadpathoor

    @nishadpathoor

    4 жыл бұрын

    @@ThinkSoftware nop.. i found ur video in youtube search only.. i mean i started with google search and ended up in ur video..

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    That make sense. Let me know did you find my videos useful? Thanks

  • @nishadpathoor

    @nishadpathoor

    4 жыл бұрын

    @@ThinkSoftware yh.. well explained..

  • @ReachEddy
    @ReachEddy Жыл бұрын

    Why API key for every signatures? Shall we put it in the header of the request? Any pros and cons with this approach?

  • @ThinkSoftware

    @ThinkSoftware

    Жыл бұрын

    Please note the API discussed are logical APIs and hence I have put API key in the function signature to explicitly show it. Using HTTP/REST is one implementation of that API in which ofcourse we will put the key in the header.

  • @zhaolin4656
    @zhaolin46563 жыл бұрын

    How do you decide to break down functionalities into services? For example, fanout service in this context is almost exclusively used by session service, so why not make it a part of the session service?

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the question. Well even all the different micro-services can be combined into a single big monolithic service however we separate them into different micro-services based on functionality. With microservices, multiple teams work on independent micro-services, enabling them to deploy more quickly - and pivot more easily when need to. Development time is reduced and each team can focus on scaling the micro-service independently from other micro-services. E.g. here session service and fanout services can be scaled independently of each other.

  • @_jatin_mittal
    @_jatin_mittal Жыл бұрын

    User last seen could also be added as an important functionality.

  • @ThinkSoftware

    @ThinkSoftware

    Жыл бұрын

    Thanks for the comment

  • @pikugoud1358
    @pikugoud13582 жыл бұрын

    all for recipient should be replaced with specific group_id since there could be multiple groups the user belongs to. Thoughts?

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    it is good suggestion..

  • @rafares
    @rafares3 жыл бұрын

    ... Awesome series, thank you very much, for next videos try not to cover the whiteboard, it is always useful to take notes on the go, before the screen is cleared...

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment :). BTW you can always pause and even replay videos if you want to take notes in between :) . Also don't worry about taking notes.. my book is coming soon which will cover these topics.

  • @taishancorp7720
    @taishancorp77203 жыл бұрын

    Around 29:38, you mentioned that when user connects with device client they will query for all messages that came after the last message ID from client. How will client know the sessions (and messages belonging to specific sessions) it need to query since all we have is Sessions and SessionMessages tables? Is there a secondary index of users and sessions as well or do they query every partition.

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the question. This has been discussed in the course.

  • @garyp20
    @garyp203 ай бұрын

    What is the lifespan/life cycle of a session? Is same sesion and session id maintained between two users for ever?

  • @jeejon9107
    @jeejon91073 жыл бұрын

    First of all thanks for all your videos. If we don't want all users to connect to same Data Center (DC), how will we implement it. Say there is Route 53 which will redirect user to closest DC. User A is connected to Asia DC and User B is connected to US DC. How will we design database in such systems. How will message from UserA reach UserB. What data is stored only in specific DC vs what will stored "globally" - any DC should be able to allow session from any user. I hope you get what I am trying to ask.

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thats a great question and would require some detailed answers that I may not be able to cover here but I think I can address in the course.

  • @reactnativeandexpo
    @reactnativeandexpo4 жыл бұрын

    Can you please briefly explain on what database to choose for storing chat use case and why ?

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    This depends on the way you are querying the data store. E.g. In case of group service, we also need secondary index on a column other than primary key so we cannot choose a database that does not support secondary indexes. If we need transaction support then we cannot use a nosql data store that does not support transactions. So now it all depends on the use case. I can go on and on. May be something for another video.

  • @dipteshsil9299
    @dipteshsil92993 жыл бұрын

    Since the groups are sharded by group Id, if I want to find all groups that a user is part of, won't that require me to go through all shards?

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the question. This is discussed in the course :)

  • @chengbohan994

    @chengbohan994

    3 жыл бұрын

    I guess in this case it is better to have global index for the 2ndary index of the table (the userid) and sharded also by userid. See discussion in 17:40. Check global index and jump to the shard with corresponding group Id.

  • @Claudius025
    @Claudius0253 жыл бұрын

    4:09 strong consistency. We wouldn't want to get messages out of order. However, we could re-order the messages with date_time. Thus, if Twitter is using eventual consistency in your demo why and if Whatsapp does use strong why couldn't any messaging service also use eventual consistency as well?

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    thanks for the comment :) . Let's see what others have to say about it.

  • @soumen_das
    @soumen_das4 жыл бұрын

    Hi! Can you teach System Design for: - Ecommerce - P2P Lending - TikTok - Banking Apps

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    Yes I have added them to list of my backlog. I think it is just a matter of time. Thanks for the comment.

  • @chitrasomasingh5388
    @chitrasomasingh53883 жыл бұрын

    Thanks for the video. Kindly, help me here that how the recipient of the "status" msg is being figured out in case of group chat. Because, let's say 1) sessionID in case of pvt msg is composed of userID1+userID2 (so here we can figure out the recipient) 2) sessionID in case of group msg is composed of GroupID only. (how to figure out in this case ?)

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    There is sender id in the message that is sent.

  • @chitrasomasingh5388

    @chitrasomasingh5388

    3 жыл бұрын

    Think Software Right. Thanks !

  • @ashwinisinha7100
    @ashwinisinha71004 жыл бұрын

    Upload trending topics design tutorial and push notification design tutorial

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    Will do so soon. Stay tuned :)

  • @ankuj2004
    @ankuj20043 жыл бұрын

    I am wondering if push notifications work even when the user is offline. I am not sure about it. If they work only when user is online, they can receive the message via usual route

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    The push notifications that I have discussed only work when user is offline.

  • @ankuj2004

    @ankuj2004

    3 жыл бұрын

    @@ThinkSoftware I am still kind of confused here . If we look at the specs it says APN /GCM stores the messags till device comes online. stackoverflow.com/questions/52522362/receive-all-the-push-notifications-when-devices-are-offline

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    User offline from whatsapp service context means whatsapp client app not running. User offline from push notifications service means the user does not have connection with PNS servers.

  • @ankuj2004

    @ankuj2004

    3 жыл бұрын

    @@ThinkSoftware this makes sense. Thanks

  • @chkmystyle
    @chkmystyle3 жыл бұрын

    Plz make video on SurveyMonkey system design

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment. Will look into this.

  • @rajatmishra9993
    @rajatmishra99932 жыл бұрын

    How do we partition group_membership table using groupId? There will be multiple entries with same group_id which will simply violate the uniqueness.

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    Thanks for the comment. I think you don't understand how partitioning works and that's why mentioning uniqueness constraint. When we partition the table based on hash of group ID then all the memberships entry for a group will be within a single partition.

  • @rajatmishra9993

    @rajatmishra9993

    2 жыл бұрын

    @@ThinkSoftware Yes. I got confused. Doing a little deep dive made me understand that. Forgot to delete the comment. Thanks anyways for answering.

  • @dragokamenov6768
    @dragokamenov6768 Жыл бұрын

    I would argue that end-to-end encryption is a non-functional requirement (security)

  • @ThinkSoftware

    @ThinkSoftware

    Жыл бұрын

    Security could be non-functional but the way it is implemented could come under functional requirements.

  • @jjc5258
    @jjc52583 жыл бұрын

    very good video, something to discuss, looks like session Id and timestamp are not able to distinguish a msg, subject to both time and sessionId are not unique, one possible way could be sequence id + msgId, sequence id is used to guarantee msg order and msgId is used to distinguish msg itself, in real world, there will be a seqId generator service to generate a latest sequence Id, this can be done within 3 milliseconds considering you have 1000 billion requests per day, seqId will be used to sync with server by the increment of seqId which means only unread msg will be load to append to user ,this service requires hundreds of instances depends on how many users we are serving, this is a super hyper important component in any large scaled IM system, should be mentioned in the design. Moreover, the two ways in the design will not work(epoch and transaction), transaction is a very bad idea, 😂

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment. The basic idea is session Id + timestamp can be then use to get the message in an ascending order where we know that timestamp will always be increasing. If we use sequence id + msg id then first of all we cannot make sure that sequence id is always monotonically increasing within a session (if we are not using the counter approach that i mentioned). In this case it would be then better to have msg id = session id + and then we need a secondary index on session id + createTime to retrieve msgs in a session in sort order by time. I have discussed the sequence generation in my previous video on designing tinyURL you can see that video to check how a sequence generator will generate sequence but there is no guarantee that it will provide you sequence in monotonically increase order against several sessions. You might have to have sequence ids per session.

  • @jjc5258

    @jjc5258

    3 жыл бұрын

    ​@Think Software that's not true, first of all, seqId can be guaranteed to be incrementally unique, I will come to that later.Before that, considering you have different senders and tons of services and also network delay, say user A send two msgs to user B, msg1 first then msg 2, if you are using server time(monotonic) you cannot solve network delay which means if for some reason msg 2 reach your server before msg 1, you will display msg 2 then msg 1 which is not right, this can happen in group chat too. For your question on seqId, the idea is each user will have an individual 64-bit sequence id which is allocated by seqSvr which I've mentioned in first comment, it will guarantee this seqId in ascending order, you can think it as a current version number, user will apply for new version number frequently(for every msg sending) and also update his/her cur version number whenever sync with server, the seqSrv will maintain each user's cur_version and also a max_version which is pre-allocated, once user's cur_version reaches max_version, seqSvr will increase it by a step(lets say 10000), for instance, initially user A is assigned a seq Id 50, and a max_Id 10000, user A send a msg, the msg will be send along with the cur_version 50 then seqSvr update user A's seq Id to 51, so on and so forth, until it reaches 10000, then seqSvr update user's max_version to 20000. So to speak, seqId is not only monotonically increasing within a session, it monotonically increasing life long. One more optimization you can think of is how to reduce the update for billions of user, because you will need to persist the seq and max_version, one thing you can do is group several users so they can have a common max_version, whoever reaches it will trigger the update, and we don't have to maintain cur_seq, we only update max_version when it reaches threshold, this can significantly reduce the cost(assume you have 10 million qps, there is no such disk can handle this I believe, correct me if I'm wrong, by doing this it will become 10^3, which is okay), also benefit recover process if seqSvr failed. Btw, this approach has been used in real world. There are many issues with timestamp approach. Lets talk something about your counter approach, question 1: how do you make it unique in different replicas? you have to make this increment in a single server first then copy to other replicas, right? then it is a single point failure. question 2: if we have billions of active users or 10 million qps, how you can handle these counter updates to database? how long will it take to recover a failure node? how can you reduce the recovery time? question 3: how can you solve network delay? like the scenario I described.

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment. Something to think 🤔

  • @tutorialsmadeeasy3505
    @tutorialsmadeeasy35053 жыл бұрын

    Thanks for the video. Say user A is out of coverage. After some time user A connects to the internet. User A receives push notification. Using push notification user A comes to the WhatsApp client. WhatsApp client sends the last session id which user A has received to the WhatsApp server. Now how does server finds all the sessions which user A has not received. Will it compute it on the fly or will it pre-compute?

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment. This is something to discuss in the incoming book 🙂

  • @tutorialsmadeeasy3505

    @tutorialsmadeeasy3505

    3 жыл бұрын

    @@ThinkSoftware So 1 message belongs to 1 session, right? I am still not able to understand how are going to create the handshake id and how handshake id will help to create encryption?

  • @KangJangkrik

    @KangJangkrik

    3 жыл бұрын

    @@tutorialsmadeeasy3505 Session supposed to stay persist for each user

  • @kartech4592
    @kartech45922 жыл бұрын

    At 27 minutes, if the recipient is ALL then it sent to all in the group, but how do you know which group to send. Sorry If I have missed the link back to the group. Please clarify.

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    From the session id, you can get the group Id. However, I think it is a good suggestion to store group Id there to avoid looking up for group id.

  • @jivanmainali1742
    @jivanmainali17423 жыл бұрын

    Hello sir! Why whatsapp web require mobile net connection enabled and how its getting messages if whatsapp delete messages after delivered

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    This is not discussed in this video. May be will discuss separately. In short, in whatsapp web, you communicate with your mobile phone over an encrypted channel and that is why you need mobile net connection.

  • @jivanmainali1742

    @jivanmainali1742

    3 жыл бұрын

    How mobile communicate to whatsapp web .Is it through web socket like when mobile get messages it emit event with new message so that it could be delivered to whatsapp web with different socket id

  • @knimr3
    @knimr33 жыл бұрын

    Thank you. I learned a lot from your videos. Highly recommended.

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment 🙂

  • @aranasrehman106
    @aranasrehman1062 жыл бұрын

    Could you please add English subtitle for this video ?

  • @aranasrehman106

    @aranasrehman106

    2 жыл бұрын

    I'm deaf, that's why I'm asking

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    I will see if I can add automatic subtitles.

  • @aranasrehman106

    @aranasrehman106

    2 жыл бұрын

    @@ThinkSoftware automatic is fine. Thank you for the response.

  • @aneeshjain3395
    @aneeshjain33953 жыл бұрын

    Commenting for better reach

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment

  • @hieuminh8020
    @hieuminh80204 жыл бұрын

    Could you please add english subtitles? Because I'm come from country with mainly language is not english so i'll be gratefull for that. Thanks.

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    I will try to. Do let me know whether the default subtitles work for you and not?

  • @hieuminh8020

    @hieuminh8020

    4 жыл бұрын

    Think Software Default is ok

  • @ThinkSoftware

    @ThinkSoftware

    4 жыл бұрын

    Thanks for letting me know.

  • @veliea5160
    @veliea5160 Жыл бұрын

    what is chat session in whatsapp?

  • @ThinkSoftware

    @ThinkSoftware

    Жыл бұрын

    A chat session is a construct to denote either a 1-1 dedicated discussion between two users of group discussion of two or more people.

  • @totsubo2000
    @totsubo20002 жыл бұрын

    First off, thanks for going into all the services! Many other videos glance over some of these components. If I could make one suggestion it would be to be more explicit every that you make a design choice due to the Scalability, Availability, and Latency requirements. One question about the message service, is the primary of the session_message table sorted? I ask because in the example you give at [29:36] when user 3 comes online you state that the message service will find all the message user 3 has not yet received based on the last message id user received. Using the last message id requires a full database scan no? Since message service table is sharded based on the group_id, I would instead have a sort key on the timestamp. This would make it efficient to find all messages for a session that were generated after a given timestamp.

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    Thanks for the comment :). Regarding your question it may or may not be sorted. This topic can't be cover in a comment. Might be a topic of different video.

  • @pareshmaniyar8273
    @pareshmaniyar82732 жыл бұрын

    What is the answer for local index vs global index? Anyone interested in throwing light on it

  • @ThinkSoftware

    @ThinkSoftware

    2 жыл бұрын

    what do you think?

  • @OmkarGhanekar

    @OmkarGhanekar

    2 жыл бұрын

    @@ThinkSoftware Local Secondary index sharded by GroupId will allow us strong consistency at the cost of scatter-gather latency whereas GSI sharded by UserId will allow us quick look ups as we need to visit only 1 partition to read the index but only provide eventual consistency as the partition where the group gets added might be on a different host than the one where the indexes(indices?) for its members reside. Given that querying for group membership is not a frequent operation but when performed it has to be strongly consistent, I believe we can tolerate scatter-gather latency of the LSI approach in favour of string consistency. What do you think?

  • @venkatramineni4789

    @venkatramineni4789

    2 жыл бұрын

    ​@@ThinkSoftware You are doing an amazing job at explaining the concepts with clarity and the reasoning behind using one over the other. Thanks for your valuable time and effort in sharing this knowledge. On the group membership partition, I guess most of the usage would be around retrieving the list of groups that user belongs to as the first thing and in this case Global Secondary Index will be useful. Once the groupIds are retrieved, then Local Index can be used for querying the groups. Please share your thoughts on this. Looking forward to more videos from you.

  • @goutamkundu6392
    @goutamkundu63922 жыл бұрын

    I am not convinced why Group_membership table is required. When a user moves to another device, then for getting groups why will he call Group Service? We should store all group ids where the user belongs in the user table itself(Sharded by userid). He'll call user service to get all his groups. And the Group table in the Group service should have also a list of members belonging to that group along with memberCount. Please clarify whether I am correct.

  • @varshard0

    @varshard0

    2 жыл бұрын

    In relational database, when dealing with a many-to-many relationship between tables. It's best to have a bridge table between them. The bridge table in this case is group_membership. This way it's much easier to do something like querying members of a group as well as querying groups that user belong to.

  • @varshard0

    @varshard0

    2 жыл бұрын

    The way you are doing is appropriate for a non relational database, but not for a relational database. You are maintaining multiple source of truth that way. Example; if a user leave a group, with relational database way, you just remove a record from group_membership table and done. For a non-relational db way, you have to remove the group from the user's record, then go to the group table to remove the user from the group.

  • @swagatikatripathy4917
    @swagatikatripathy49173 жыл бұрын

    Support for stickies and emoticons

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment 🙂

  • @karthiksethu4816
    @karthiksethu48163 жыл бұрын

    Instead of sessionID and sharding the messages based on sessionID, it would be simple to shard the messages based on groupID. In my thinking there is no concept of session. Everything is based on groups. Dedicated chat is nothing but a group of 2 people. If you define it that way then you don't need to differentiate between dedicated and groups. Now i can shard and find messages using groupID. Also I would keep timeline view of last 200 messages of a group in Cache [Similar to newsfeed or timeline] This will have monotonically ordered messages of a certain group. If a new message comes in after inserting in to the db i will also write in this group timeline. Now members of the group will retrieve the messages from this cache [pull model when they coming online after being offline] After writing this to the cache then i do fanout to push it to the group member devices [to all active members who are maintaining web socket connection with our servers.

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks for the comment. Group service only stores the group membership. Session (or more correctly chat session) service stores all the messages that belong to a chat session (whether dedicated or group chat sessions).

  • @karthiksethu4816

    @karthiksethu4816

    3 жыл бұрын

    @@ThinkSoftware Thanks for the reply. Got it, you create a chat session when a new dedicated/group chat is formed. And you create 1 session per chat. Say me and my friend are chatting there will 1 session managing our chat. Sure it will work. If that is the case why create a new PK sessionID, can we reuse the same primary key GroupID. Good videos by the way, you go in to lot of details than other content online.

  • @ThinkSoftware

    @ThinkSoftware

    3 жыл бұрын

    Thanks. You can use the same ID but what is the advantage?

Келесі