System requirements

Functional:

1. client is able to increment/decrement the counter by 1. and the system will return response with success or failure
2. client is able to retrieve the total count in real time

Non-Functional:

1. eventual consistency is acceptable
2. high availability
3. high scalability
4. low latency

Capacity estimation

1. QPS: 10000
2. 10000 * 86400 * 100 bytes = 100G / day
3. 100 G * 365 = 40TB

API design

1. POST /counter/increment
2. request body: None
3. response: 200 OK
4. POST /counter/decrement
5. request body: None
6. response: 200 OK
7. GET /counter/total
8. response: 200 OK with current total count

Database design

Redis:

key: global_counter_key

value: count_value integer

High-level design

when a client sends increment/decrement request, app server receives the reqeust and send request to redis to increment/decrement the counter in it.

graph LR

A((Client)) --> B(Application Server) --> C(Redis Database)

B --> D(MySQL Database)

Request flows

graph LR

A((Client)) --> B(Application Server) --> C(Redis Database)

B --> D(MySQL Database)

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

1. we need multiple app servers to handle request from different clients, since the QPS is high.
2. we need a load balancer in front of app server to forward requests to different app server, we can use round robin strategy here
3. in order to avoid single point of failure, we need to create replicas for redis with master-slave architecture, one is master to handle write and read request, other 2 replicas can only handle read request

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?