System requirements

Functional:

- 1 on 1 chats

- group chats

- chats stored in db, can be resumed on other devices

- media

Non-Functional:

Performance:

• want service to be close to real time

Availability:

• want service availabile > data consistency

Scalability

• use a NoSQL database for availability and eventual consistency
• use a load balancer with IP hashing so load balancer connects users to servers closest to them, reducing latency
• 10:1 read to write
  • master-slave replication
  • messaging queue handles replication

Security:

• make sure we track user session's so they dont have to re-login on devices

Capacity estimation

assume 1 million users daily

20 messages a day

40 bytes for text and metadata

not include compression or media

1mill * 20 * 40bytes = 800000000 bytes / day = 800 mb/day = 0.8 GB / day *365 = 292 GB / year

292 * 5 = 1460 GB / 5 years = 1.46 TB / 5 years

API design

/sendMessage

(senderId, recipientId, message: obj)

check if a chat already exists

else, create a new chat in database

If media in message, upload to cloud. save cloud URL in media document

return error if upload not successful

return error if server timeout

save new message in database

return 200 if message sending was successful

/uploadMedia

(mediaObj: obj)

for each media item in the obj, generate a new UUID

upload the new item to the cloud; save the URL in a variable

save the mediaId and url in the media document

return 200 if successful; return an error if any upload failed

Database design

database schemas:

users

userId UUID

firstName string

lastName string

created datetime

chat

chatId UUID

chatName string

creator UUID

chatToUsers

chatId UUID

userId UUID

message

messageId UUID

chatId UUID

sender UUID

recipient UUID

sentAt datetime

media

mediaId UUID

url string

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

• sharding based on geolocation. Instead of having a monolithic database, we can have different shards all over the world to reduce latency for our users.
• primary-replica replication to try to prevent data loss
• denormalize the database to improve read performance of our database. denormalization is adding redundant data to our database to improve read performance.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?