System requirements

Functional:

• Users can chat with each other in groups of 2 or more
• They get a notification when there's a new message

Non-Functional:

• High performance
• Can handle many users at once
• Up to 10 users in a group chat
• Messages are show in order of server time
• No media for now

Capacity estimation

• Each message is 100 bytes
• 1 billion users
• Each user sends 5 messages a day
• 1,000,000,000 * 5 * 100 = 500,000,000,000 Bytes = .5 TB a day

API design

POST v1/message

Body: Group ID, message (100 char limit)

GET v1/messages/{group_id}

Database design

Messages DB:

• Cassandra for leaderless replication, there are no edits so we are write only so leaderless give us fast writes and no issues on calls clobbering each other
• Index: Group ID: number, sort key: timestamp, content: string
• Partition on Group ID for fast access

SQL DB:

• Users table: ID (auto-inc) and name of user
• Groups table: ID (auto-inc) and name of group
• Membership table: User ID (foreign key), Group ID (foreign key), membership type (basic, admin, etc)

High-level design

We need a client, service, Cassandra DB and a SQL DB

Request flows

Home Screen (see all the chats you are in):

Client -> Service -> Query Memberships Table

In Group Chat:

See messages:

Client -> Service -> Query Cassandra table for messages with Group ID

Send Message:

Client -> Service -> Write to Cassandra DB

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

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

Image support using blob storage and CDNs