System Requirements

Functional

1. Real time display of the total user count currently viewing a web page or web site
2. Upon exit of the user from the website, the value in the counter decreases by 1
3. Provide users with the count of unread notifications upon modifications to subscribed web pages

Non-Functional

1. Availability
   1. The service should be highly available
   2. The service can never go down
2. Consistency
   1. We are okay with consistency being less important than availability
   2. We aim for eventual consistency
3. Accuracy
   1. The counter should be accurate
4. Scalability
   1. The service should be able to handle a large number of concurrent users
   2. The service should be able to handle a large spike in the number of users
   3. The service should be able to accommodate a growing user base in the future
5. Latency
   1. Should be kept low

Capacity Estimation

1. We assume that 100 million users will be connected to the service at any given time
2. This will be read heavy system with the read to write ratio being around 10:1
3. Peak traffic will be assumed to be around 200 million users concurrently

API Design

1. Get current counter value
   1. GET
   2. Gets the current value of the counter
   3. Returns a success message (200 OK) in case of success, error otherwise
   4. Along with the message, returns the counter value along with the timestamp of when it was last updated
   5. Response is received in the form of a JSON
2. Increment/Decrement the current counter value
   1. PUT
   2. Updates the value of the counter by +1 or -1, depending on whether the user got connected to the website or left it
   3. Returns success (200 OK) in case of success, error otherwise
   4. The parameters are passed to the service in the form of a JSON

Database Design

classDiagram class User { id: integer name: string email: string profile_picture: string created_at: datetime } class Page { id: integer title: string user_id: integer content: text created_at: datetime } class Counter { page_id: integer created_at: datetime updated_at: datetime count: integer } User "1" -- "n" Page : owns Page "1" -- "n" Counter : has

1. The primary tables in case we go with a relational database are the user table, page table and the counter table
2. The user table would hold details of the users registered on the website
3. The page table would hold details of each page of the website
4. The counter table would holds data regarding the current count of the pages
5. In contrast to the design defined above, using a non-relational database would mean data would be de-normalized prioritizing faster query operations
6. We can also utilize an in memory data store to keep the current count of the counter since we are only interested in the current and historical count has no value to us apart from analytics
7. Non-relational databases would lead to better reads and writes than a relational database since non-relational databases employ a multi leader replication scheme and that would mean we can do reads and writes at any data nodes that would cut down on the possibility of a particular node becoming a hot spot, as would be the case with a relational database since it employs a single leader replication and all writes are handled by the single leader
8. We can employ a hybrid system where we have a primary on disk database that keeps hold of the current count and a separate in memory data store that keeps a track of the users currently on the website and then syncs with the on disk data store every M minutes, where M is a configurable parameter

High-Level Design

flowchart TD

client[Client]

zookeeper{ZooKeeper}

loadBalancer{Load Balancer}

apiGateway[API Gateway]

messageQueue1[Message Queue]

messageQueue2[Message Queue]

database[Database]

cache[Counter Cache]

countServer[Count Server]

client --> loadBalancer

loadBalancer --> apiGateway

apiGateway --> messageQueue1

messageQueue1 --> countServer

countServer -- write --> cache

cache --> messageQueue2

messageQueue2 --> database

countServer -- read --> database

1. We use a message queue to decouple components
2. The Count Server hits the counter cache and updates the value for the corresponding page there
3. Every M minutes the counter cache takes all the values in it and puts in a message in the message queue
4. Every M minutes, the database pulls the data from the message queue and updates the value of the counter, this is the pull model
5. To do reads, the counter server gets the value from the database
6. Zookeeper works as a coordination service connecting a user to the previous server they were connected to. It can store this information in the form of a key value store

Request Flows

1. The moment a user enter the website, we use the second API and increment the current view count for that page by 1
2. If the user moves to a different page, we decrement the count of the previous page by one and increment the count of the page the user is currently on
3. When the user quits the website, we again decrement the count of the last page the user was on by 1
4. All read operations for the current count are catered to by the database

Detailed Component Design

1. We can use a key value store for our in memory cache database that supports increment and decrement operations
2. When updating our counter value in the database, we first aggregate our count across all the Redis clusters and put in a message in the message queue
3. After the values have been updated in the database, all Redis clusters are reset to 0 and we begin counting again

Trade Offs/Tech choices

1. For our in memory key value store, we use Redis as it offers the functionality of increment and decrement which is our entire use case here
2. For our primary database, we can either use MySQL if using a relational database, otherwise, Cassandra if going with a non-relational model
3. For our message queue, we use Apache Kafka since it is a log based message queue and will not lose data
4. For our coordination service, we use Apache Zookeeper

Failure Scenarios/Bottlenecks

1. Our Redis clusters can fail, leading to incorrect count
2. There can be delays in updating the current count in the database

Future Improvements