Designing Facebook Messenger

-


 Functional Req

  • One to one or groups chatting

  • Receipts / Statuses

    • Online/Offline

    • Sent

    • Delivered

    • Read

  • Multimedia Sharing

  • Security

Capacity Estimation 

500M daily active users, average each user sends 40 messages daily = 20B daily messages


Storage: 

A message ~100 bytes * 20B = 2TB/day. 

in 5 years : 2TB * 365 days * 5  year = 3.6PB

We need to scale. 


Bandwidth:

2TB everyday data per second : 2 TB /  86400 sec ~= 25 MB/s

High throughput we can scale.

High-Level System Design



Logic Flow


Heartbeating 


UserA goes to load balancer.  LB will pick one the host behind based on load average or number of connections.  LB picks N1 - App server. Web socket connections bi-directional nature both server and the client can initiate a request. 


At this point, while the UserA is not sending any data. They are just heart beating between them. 

Why do we need to constantly heartbeat? Because the server knows that User A is still there and also User A knows the N1 - App server still there. 


We can store this relation in the cache (Redis). No need to store DB for heartbeat data. 


User     | Server | Heartbeat Time

User A   | N1       | T1

User B   | N2       | T2


Redis is a distributed cache. It holds all the data in memory. We can multiple 3 at least every tier.  Write and read super fast from the cache. 




N1 - App server die? 

Websocket connection will incentive break. User A will know that the other end of the server died. It will initiate a new connection with the new server and the N1 App server is going to update Heartbeat information. 


If User A dies or inactive or offline?

It stops heart beating with N1 - App server then N1- App server start to update heart beating data. 

This data provides some notification on the client-side. Like this user online at 5 minutes ago or one hour ago. All this information retrieved from Cache- redis using last time heart beating data. 


Messaging Handle


  • User A friends of User B. User B is also online 

  • User A sent to message N2 - App Server that let’s say “Hi”.

User A  ---> “Hi” ----> User B

  • For the high throughput, sends a message to an in-memory message queue with the user, server, and message information. Q can store this data to the DB this message. 

  • In-memory tier sends back ‘sent’ notification to User A.

  • Task threads send back the message to the app server based on each receiver session.

This logic in Queue can check who is managing user B to check the Cache - Redis.

User     | Server | Heartbeat Time

User B   | N2       | T2

N1    --- >   N2 

And N2 App server sends this message back to UserB

  • N2 App server sends the back status of delivery.

  • User A will update the status ‘Delivered’

  • We can store persistent DB all these processes through the Message Queue.



Offline to Online Process


User A wants a message to User C. But User C is offline that now. 

User A --- > “Hi C”  ---> User C

No entry in the Redis cache about User C. User C is offline no one is managing that. 

Just write messages to the DB which could be the “Unread Messages” table by using message Queue.

When User C  does come online, whoever is managing user C let’s suppose N3 - App Server. 

App server will update to the cache. 


User     | Server | Heartbeat Time

User A   | N1       | T1

User B   | N2       | T2

User C   | N3       | T3


We know who is managing User C > N3. N3 App server starts the same process. It requests the Messaging Queue and getting Database “Unread Messages” relative data about the User C. Then N3 App server going to transmit all that information to User C.

We can remove from “Unread Messages” and we can write to the  “Read Messages” table.




Encryption


We need to encrypt all content in our messaging system. 

We have a master key in our applications. We should encrypt using this master key all content. 

And every message should be store encrypted key in the DB or cache. 






Media Sharing like Picture


Let’s say User A sends User B a picture by the same encryption.


N1 App server gets the request then we can add a new queue to send N2 App Server.

This picture in the Blob Storage in an encrypted format which is encrypted User A has the key. 

And we can store this original Url in our DB  in the “Conversation Table”.

The same process gets a heartbeat where is the User B Server. 

N2 Server will send just a thumbnail image and original URL to User B.

The original picture could be 5 MB, but the thumbnail just could be 5 kb.

Thumbnail would see in User B. If User B click this thumbnail we will take this URL and download the entire picture for the user B. But the image comes together encryption. But our encryption key help of this see this picture. 

Comments

Post a Comment

Popular posts from this blog

Design a notification system

-
Image
Design a notification system Functional Requirements Users receive notifications as the events happen within the platform Users can subscribe to a channel to receive all relevant notifications Users can receive notifications in their respective client app (Mobile, web, integrations) Notification can be rate-limited Non-Functional Requirements Always available Easy to add new clients Scalable: Linearly scalable What is the scale of the system? Average of 50k notifications a day  — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —  Could there be Some Questions — Answers? What kind of notifications? Push notification, SMS, EMail What have supported devices? IOS, Android, Laptop / Device Design Constraints Average of 50K notifications a day. Per notification would be 100 chars. Every char 2 Byte. 100 chars X 2 Byte = 200 Byte And we need to store some metadata(Id, user_id, date, device_type etc. ) for notification , and we assume 100 bytes : 200 * 1000 = 20000 bayt 50.000 * 2000
Read more

NETFLIX HIGH-LEVEL SYSTEM DESIGN

-
Image
  STEP - 1 Functional Req   User Registration + login + profiles Search Recommendations Activity tracking Recommendation generation Dashboard Payment Content Ingestion and Delivery Rights + Licences Categorization Notifications Trend Movies Watch History Endorsement Design Constraints Number of users: 100 million Daily active user: %10 Content Upload / sec: Minimal Content Streamed / sec: Need scaling  How many videos let’s say 20000 Averaga per video 10 GB : 3gb HD + 1gb sd = 4 gb.  Avg per video 2,5 hours = 10 GB Content Size: the average size of the video data User activity tracking: High Content streaming latency STEP - 2  Define Microservices We can bucketize functional requirements into Microservices.   The system is a huge system so should be a lot of teams to handle these requirements.  Multiple Microservices - Breadth Oriented System. High Priority Microservices  Microservices  Technology Type User activity tracking MS Simple time-series K-V workload with TTL/count Recommendat
Read more

URL Shortener System Design

-
Image
STEP 1  Functional Req. Given a Long URL, generate a unique short URL. Given a short URL, redirect to a long URL Customized URL,(User should be able to pick a custom short link) TTL (User should be able to specify the expiration time) Non-Functional Req. The system should be highly available. With min latency Non-predictable Analytics Design Constraint Generated per second Length of the short URL,  Let’s start with 7 Char set in the short URL; A-Z, a-z, 0-9 STEP - 2 Microservice Design Decision URL Shortener Microservices All requirements can handle the same team A single microservice - A depth-oriented problem STEP - 3 Drawing logic architecture STEP - 4A  TIERS Default we can multiple every tier 3X  App server tier, In-memory Tier, Storage Tier Data Model Short URL/unique ID, Long URL, TTL, creation time K: Short URL/unique id,  V: Rest of the stuff APIs create(Long URL) -> create(V) read(short URL) -> read(K) Similar to CRUD APIs create (K,V), read(K), update(K,V), delete(K)
Read more