System requirements

Functional:

• Send current user status on website
• Online, Offline, Idle

Non-Functional:

• Scalable
• Reliable
• Available

Capacity estimation

• UserID -> 7 char base64 decoder -> 7 bytes
• Status -> 7 bytes
• TimeStamp -> 4 bytes

18 bytes -> 18000000 bytes -> 18 MB

Because its taking so little memory, no need to scale DBs yet

API design

• /GetStatus -> Get user's current status
• /PostStatus -> Set user's current status

Database design

Status Table:

• UserID
• Status
• TimeStamp

High-level design

• Client -> Loadbalancer -> Rate Limiter -> Server -> Database
• Read heavy to display user status to people who have added you
• Replicas

Request flows

Client -> Loadbalancer -> Rate Limiter -> Websocket -> Server -> Database

Detailed component design

Client side can calculate inactivity and send idle status after x amount of time of no activity

Client can directly set status

Client would also establish a websocket connection to get real time update of their friends statuses

ServerSide would send status update with timeStamp to clientside to clients through the websocket

Use Pub/Sub pattern along with websocket to update everyones friends list when a friend changes status

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

Too many writes to update status at a time

• Can shard database to refrain from overloading a single DB with writes

Future improvements

Add features depending on what users request

Possibly add a chat system