2 micro-services: Chat Service : serving the traffic - messages sent check if receiver - online or not. If online - send message - instantly. Transient Service : maintain messages - sent to offline users. Msg stored temporarily - until the user online.

diag

Store details : server - to which the user is connected time - user active last can use a document-based DB E.g: MongoDB - to store - user last active time (heartbeat time). 

Transient Data Storage





Ensure that our service # meet the user demands - high availability & low latency. can define SLAs for these metrics # create moderate and severe monitors which can trigger an alarm when these SLAs are violated. For Messanger # define the following SLAs for the sendMessage API. Availability SLA: p99.999 # alarm if more than 1 out of 1000 requests fail Latency SLA: p99.99 of 5 milliseconds # alert triggered if server takes >5ms to respond # for more than 1 out of 100 requests it receives The availability SLA implies that that the monitor will trigger an . Additionally # we can put failure alarms in different error scenarios.

Extend the system - to support group chats Group-table # GroupChatID maintain a list of people - part of group.

Chat Server failure

transient server failure

 Connection is maintained bet client & server - WebSockets. Once an initial connection is established between client and server, the communication switches to a bi-directional binary protocol. The connection is kept alive between client and server using heartbeats. We store the last time a heartbeat was received from a user in a database. The data-storage can then be queried to fetch the last time a user was active.

Optimization