System requirements

Functional:

• Send messages
• Receive messages
• List contacts
• Store old messages
• Get new messages in realtime

Non-Functional:

• Minimal latency
• High availabity
• Strong consistency (message ordering...)

Capacity estimation

• 500M daily active users
• Each user send 10 messages daily
• 5B messages sent daily
• ~100 bytes per message
• Storage growth of ~465GB each day

API design

Note: authorizations are handled via a token in http header or a session cookie so users don't need to provide their identity as a parameter of the APIs

POST /v1/message/send

inputs : { recipient, content }

GET /v1/message

input : { contact }

output : { list of messages }

GET /v1/contacts

ouput : { contacts}

POST /v1/contacts/add

DELETE /v1/contacts/delete

input : { contact_id }

Database design

Users

• [PK] ID
• login
• email
• password
• created_at

Contacts

• [FK] user_id
• [FK] contact_id

Messages

• [FK] user_id
• [FK] contact_id
• text_content
• timestamp

High-level design

There are three services that can be scaled independantly

• messages services : send & read messages
• contacts service : add, remove and list contacts
• realtime notifier service : push notification to the client when a new message is received

Request flows

• A user add a new contact using the contacts service
• Then the user send a message to this contact via the messages service
• The message service add the new message to a queue
• The message service tell the realtime notifier service to push a notification to the contact

Detailed component design

• The message queue is durable (storage to non volatile memory)
• Messages are idempotent (no duplicates) thanks to an id generated on the client side
• The message queue can be partionned using the hash(user_id, contact_id) as a key

Trade offs/Tech choices

• We use a websocket connection between the client and our servers in order to deliver messags in realtime

Failure scenarios/bottlenecks

• If the database is unavailable (overloaded or offline) the messages are not lost thanks to the serializer queue
• Alternatively if the message queue is unavailable we can serialize the messages directly to the database as a fallback mechanism
• We send a notification only if the message has been correctly added to the message queue
• The queue helps withstand peaks of traffic

Future improvements

• Ability to send media alongside the text message
• Monitoring and analytics