Requirements

Functional Requirements:

• Track online presence for users logged in from multiple devices, aggregating into one overall status per user.
• Presence is visible to other users (e.g., friends list, chat roster, profile).
• Presence changes propagate to interested viewers without polling (push/streaming).
• last seen support
• Log transitions for analytics such as active time, sessions, usage patterns.
• historic presence logs for logging transitions

Non-Functional Requirements:

• High Availability
• Low Latency - sub second propagation around 20ms
• Horizontal Scaling
• Strong Consistency
• Concurrency
• Network Efficiency by optimizing network topology and quality of service configuration. along with route dampening techniques for better flapping tolerance.
• Security by adding authentication to the users.

API Design

GET /ws/v1/{userID}/presence

GET /ws/v1/{userID}/batchPresence

POST /ws/v1/{userID}/subscribe

POST /ws/v1/{userID}/unsubscribe

GET /api/v1/{userID}/lastSeen - it will include details like all the last seen of the user and his active time analytics as well.

GET /api/v1/{userID}/metrics

POST /api/v1/{userID}/alive

High-Level Design

Read: Client -> API Gateway -> Load Balancer -> Presence Service -> Kafka queue -> Redis -> Mongo

Write: Client -> API Gateway -> Load Balancer -> Presence Service -> Kafka queue -> Mongo -> Redis

Subscribe and Unsubscribe: Client -> API Gateway -> Load Balancer -> Sub-Unsub Service -> Kafka Queue -> Redis -> Mongo

Metrics: Client -> API Gateway -> Load Balancer -> Metrics Service -> Kafka Queue -> Redis -> Mongo

Analytics: Client -> API Gateway -> Load Balancer -> Analytics Service -> Kafka Queue -> Redis -> Mongo

When ever the cache is to be update we have a cleanup service to clean up the old entry from the cache.

Since each user can have multiple devices we can simply have a entry for each device and which ever device is only we will show online if none are online then shown as away.

When a user disconnects we will wait for 5 minutes before shown as offline in the mean time we will be showing last seen status.

When a user goes online the users who have subscribed for his status notification will receive the online status. When he disconnects users are notified of his last seen before 5 mins. After that they will be shown offline along with last seen.

We have kafka queue to handle graceful degradation if a service goes down it can pickup where it left off based on what is in the queue and what its subscribed to in the kafka queue.

Presense service handles the presense related apis like get presense and get batchpresense and post userpresense to database.

Sub-Unsub service is used to subscribe or unsubscribe users to a users status.

metrics service is used to get all the metrics related to a user as mentioned in the functional requirements.

Analytics service is used to use the metrics we got and make an analytical dashboard for getting patterns and alerts.

Detailed Component Design

API Gateway used to route the traffic based on the api that was hit. It can also be used to rate limit the requests to prevent DDoS and Brute force attacks. It can also be used for authenticating users.

Load Balancers are used to balance the load that is spread to the servers/services evenly or based on any load balancing pattern. We will be using even distribution which will be efficient for our use case.

Kafka Queue used to queue the messages and requests and is helpful in graceful degradation making things more resilient and lets services pickup from where they left before they went down.

Redis is the primary cache for our application where we will be using LRU eviction policy to remove the entries from the cache and use write-along strategy to write to the cache.