Snap Chat
- This messenger sends snaps. Plain text cannot be sent or send very rarely.
- snap = Text + Video OR
- snap = Text + Image.
| FB-Messenger | Snapchat | ||
|---|---|---|---|
| Creating Groups | y | y | n |
| Encryption | y | y | n |
| Media | Images/video/documents/audio | same as fb-msg | Images/video |
| Location sharing | y | y | n |
| Storage/Backup | images,text gets stored in gallery | same as fb-msg | not allowed |
| Automatic Deletion on Images | n | n | yes in 24 hours |
| Use case | - | messaging & sharing important documents | For entertainment |
1. Requirements
- Functional
- a. Sending snaps: User-A can send snap(Video, images, text) to user-B.
- b. Holding & Deleting snaps:
- Snapchat service should hold the message for 24 hours, if in case user is not online and snap cannot be delivered instantly. Eg: User is Flight, once user comes online snap gets delivered to him, then snapchat server can delete from its DB.
- if user is online, service will deliver message and delete snap instantly from DB.
- c. Searching a user: Unique userId is provided to users and all users are searched on basis of userId not phone numbers.
- Non-Functional
- a. User-A can add any user as his friend based on userid and send snap.
- b. [Thumbnail to be shown to reciever.
- c. Normal filters on video,image provided to sender
- d. System should be Eventual consistent & Highly available.
- Extended
- a. Blocking the users
- b. Following a user
2. BOE
snapchat revleaved in 2018 that number of snaps sent per day = 4 Billion. Assumed in 2021 = 10 Billion
- QPS(Queries per second)
- 10 Billion / 86400 = 1010 / 105 = 105 = 1 lac queries per second
- Storage Estimates: Will try overestimate
App Message: Metadata:75 bytes, Video:1MB
Dst_user_id(10 bytes) Allowed 20 characters. 1 character:4 bytes
self_user_id(10 bytes) Apart from IP address, client will send its unique user id
timestamp(4 bytes) Time elapsed from epoch(1 Jan 1970) in seconds
Text(50 bytes) Text sent with vieo or image
Video(1 MB) Video message
|App message|TCP(20 bytes)|IP(20 bytes)|DL(18 bytes)|
//Note TCP,IP,DL Headers are not stored, these are used by router not snapchat.
1 day //Assuming snapchat stores offline user data for 24 hours only
Metadata = 75B x 10 Billion = 750 Billion = .7 TB //1 High end computer having 1 TB Hard disk
Videos = 1MB x 10 Billion = 10 pow 15 = 1 PB //1000 High end computers having 1 TB Hard disk
3. API Design
- All API's should be extensible, ie if in future want to add new parameters that can be added). Variadic Templates C++.
A. Sender call these APIs
- Deduplication is avoided using messageId. if server finds messageId already in DB, it will consider message as duplicate and discard it.
sendMessage ( string dst_user_id,
string src_user_id,
uint32_t timestamp, //sec elapsed from Epoch(1/1/1970)
string text, //
uint8_t video,
uint32_t messageId) //Identifies every message Uniquely.
B. Reciever call these APIs
- Reciever will get snaps from server in 2 ways:
- a. PUSH: Whenever reciever comes online, server pushes the pending messages.
- b. PULL: Whenever reciever want to get messages it refreshes and takes message from server.
struct Message_details {
string text,
string video_url_on_object_store,
string src_user_id
}
GetMessages (string self_user_id, //Pull API
uint32_t get_messages_after_timestamp,
Message_details[]
)
PushAllMessages (Message_details[]) //Push API
4. HLD
Requirement-1: Sending snap from UserA to UserB Steps(7-10)
- 1. User opens snapchat app. Name resolution done using DNS.
- 2. CDN will be hosting user feed, periodically updating the page from App Server. CDN renders the feed.
- 3. User creates a snap, upload a (photo, Video).
- 4. User-B and sends to App-Server using ISP in JSON/XML in http.
App-Server User-A
<- HTTPS(UserA_id, dst=UserB_id, timestamp, text, Video, messageId) | TCP | IP | DL |-
- 5. HTTPS message is decrypted using SSL Terminators.
- 6. Load Balancer selects App server based on Least Response Time Scheduling algo and sends packet.
- 7. Application-Server will send User_B_id, timestamp, messageId to DBFinder service.
- 8. DBFinder:
- Purpose of DBFinder?
- Find and searches DB which stores table of User_B, that messageId exists or not, if not updates DB //See DB Design
- Respond to AppServer, if messageId exits its duplicate else not
- Avoiding Deduplication?
- Every user's snaps are stored in DB until he reads them. Eg: When User_A sends snap to User_B. This snap is stored in User_B's table in DB.
- AppServer will check User_B's SQL Database table that
messageIdexists in table or not?- Worldwide all snapchat clients But once message is delivered, AppServer will inform clients to reuse/reset the messageId
- if messageId exists then its duplicate message, drop it.
- We will place a Cache(Eg: Redis or Memcached). Redis preferred between Application server and DB.
- Purpose of DBFinder?
- 9. Video,text,images are stored in different Databases(See DB Design), user-B,timestamp are pushed on MOM, user is acknowledged using zookeeper.
- 10. Sender Service will be subscriber to MOM and recieves (userB, timestamp). It will read DB_userB and send video,image,text to userB.
Requirement-2: Holding & Deleting snap (Steps 11,12)
- 11. After sender service receives ACK from user that message is read, it will push MessageId, userId on MOM.
- 12. Deletor service gets notifcation, reads messageID,userID from MOM, checks same in DB and deletes promptly.
- cronjob would be running on Database to delete the contents if age>24 hours.
Requirement-3: Searching the user
- Application server will delegate task to DB-Finder to search userB database, if database is not found this means user is not present.
5. DB Design
- We can store information in SQL or noSQL database.
1. SQL DB Design
- User's Table
- Has one-to-many relationship with photo table, since 1 user can have multiple photos.
Primary Key: userID
| UserID | messageID | TextURL | VideoURL | Timestamp | src_UserID | email |
| ------ | --------- | ------- | -------- | --------- | ---------- | ----- |
| User_B | kanskna | <> | <> | 123 | User_A |a@a.com|
- Photo Table
- All photos which are posted by particular user. Each photo will have incremental photo-ID
- Photos will be stored in any distributed File Storage server: HDFS or GFS.
Primary Key: photo ID
| Photo-IDs | User-ID | Caption | location | Time of upload | URL |
| --------- | ------- | ------- | -------- | -------------- | ------ |
| 1 | user-A | <> | <> | epoch time | - |
| 4 | user-B | <> | <> | epoch time | - |
| 6 | user-A | <> | <> | epoch time | - |
- Video Table //Similar to Photo Table
- Follower Table
- let userA(follower) follows userB(followee).
| Followee | map<Followers> |
| -------- | -------------- |
| UserB | UserA |
2. NoSQL DB Design
- We can store same data in noSQL Databases(Eg: dynamoDB, Cassandra) since noSQL are highly scalable, hence highly available and low latency.
- Photo Table (Key, value)
- Key would photoId and value would be object containing all metadata related to photo(Eg: location/url, timestamp, size etc)
| UserID | <Key=PhotoIDs, value=Object_Containing_all_metadata> |
| --------- | -------------------------------------------------------------- |
| userA | key=photo-1, Value=Object<Location_of_photo, timestamp, size > |
| key=photo-2, ... |
```
