Real-Time Presence Platform System Design

Usually, a green colored circle is shown adjacent to the profile image of the client to indicate the client’s presence status as online. The presence status can also show the last active timestamp of the client [1], [9]. The presence status feature offers enormous value on multiple platforms by supporting the following use cases [10]:

• Enabling accurate virtual waiting rooms for efficient staffing and scheduling in telemedicine
• Logging and viewing real-time activity in a logistics application
• Identify the online users in a chat application or a multi-player game
• Enable monitoring of the Internet of Things (IoT) devices

Terminology

The following terminology might be helpful for you:

• Node: a server that provides functionality to other services
• Data replication: a technique of storing multiple copies of the same data on different nodes to improve the availability and durability of the system
• High availability: the ability of a service to remain reachable and not lose data even when a failure occurs
• Connections: list of friends or contacts of a particular client

Questions to Ask the Interviewer

Candidate

1. What are the primary use cases of the system?
2. Are the clients distributed across the globe?
3. What is the total count of clients on the platform?
4. What is the average amount of concurrent online clients?
5. How many times does the presence status of a client change on average during the day?
6. What is the anticipated read: write ratio of a presence status change?
7. Should the client be able to see the list of all online connections?

Interviewer

1. Clients can view the presence status of their friends (connections) in real-time
2. Yes
3. 700 million
4. 100 million
5. 10
6. 10: 1
7. Yes, the connections should be grouped into lists, and the online connections should be displayed at the top of the list.

Requirements

Functional Requirements

• Display the real-time presence status of a client
• Display the last active timestamp of an offline client
• The connections should be able to see the presence status of the client
• The client should be able to view the list of online clients (connections)

Non-Functional Requirements

• Scalable
• Reliable
• High availability
• Low latency

Real-Time Presence Platform Data Storage

The timestamp of the latest heartbeat signal received must be stored in the presence database to identify the last active timestamp of the client. The relational database with support for transactions and atomicity, consistency, isolation, and durability (ACID) compliance can be an overkill for keeping presence status data. The NoSQL database, such as Apache Cassandra, offers high write throughput at the expense of slower read operations due to the usage of an LSM-based storage engine. Hence, Cassandra cannot be used to store the presence status data.

A distributed key-value store that can support both extremely high read and extremely high write operations must be used for the real-time presence database [1]. Redis is a fast, open-source, and in-memory key-value data store that offers high throughput read-write operations. Redis can be provisioned as the presence database. The hash data type in Redis will efficiently store the presence status of a client. The hash key will be the user ID, and the value will be the last active timestamp.

Real-Time Presence Platform High-Level Design

A trivial approach to implementing the presence platform is to take advantage of clickstream events in the system. The presence service can track the client status through clickstream events and change the presence status to offline when the server has not received any clickstream events from the client for a defined time threshold. The downside of this approach is that clickstream events might not be available on every system. Besides, the change in the client’s presence status will not be accurate due to the dependency on clickstream events.

Prototyping the Presence Platform With Redis Sets

The sets data type in Redis is an unordered collection of unique members with no duplicates. The sets data type can be used to store the presence status of the clients at the expense of not showing the last active timestamp of the client. The user IDs of the connections of a particular client can be stored in a set named connections, and the user IDs of every online user on the platform can be stored in a set named online. 

The sets data type in Redis supports intersection operation between multiple sets. The intersection operation between the set online and set connections can be performed to identify the list of connections of a particular client who is currently online.

The set operations, such as adding, removing, or checking whether an item is a set member, take constant time complexity, O(1). The time complexity of the set intersection is O(n*m), where n is the cardinality of the smallest set, and m is the number of sets. Alternatively, the bloom filter or cuckoo filter can reduce memory usage at the expense of approximate results [4].

The client-side failures or jittery client connections can be handled through the key expiration pattern. A sliding window of sets with time-scoped keys can be used to implement the key expiration pattern. In layman’s terms, a new set is created periodically to keep track of online clients. In addition, two sets named current and next with distinct expiry times are kept simultaneously in the Redis server.

When a client changes the status to online, the user ID of the particular client is added to both the current set and the next set. The presence status of the client is identified by querying only the current set. The current set is eventually removed on expiry as time elapses. The trivial implementation of the system is the primary benefit of the current architecture with the sliding window key expiration. The limitation of the current prototype is that the status of a client who gets disconnected abruptly is not reflected in real time because the change in presence status depends on the sliding window length [5].