Loading...
List the key functional requirements for the system (Ask the AI for hints if stuck)...
set the key value pair
get the value when looking for the key
delete the content
update the content
List the key non-functional requirements (performance, scalability, reliability, etc.)...
We can imagine that the QPS is reading 100k and high peak QPS is 200k. The writing QPS is 10k while the peak updating QPS is 20k.
Scalability: The storage will be very large. 100b * 100k * 36000 ~ 1TB, it's very large for the storage.
Low latency: We need to return the result under 500ms so request low latency.
consistency: we need strong consistency but can treat be traded off a bit availability.
fault tolerant: When the operation failed, we need to send the request again until successful
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
POST /v1/api/data, body是 {"key": "key1", "value": "v"} return status
GET /v1/api/data?key=key, return value and status
UPDATE /v1/api/data?key=key1. return value and status
DELETE /v1/api/data?key=key1 return status
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
APIGateway is for routing/rateLimit/security/load balance.
This is high qps. so splitting into two severs: one for updating/writing/Delete and other one for reading.
Read server: This will handle all read operations and will connect with cache to improve latency
Write Server: This will handle all update/delete/post operations.
Database, we can use NOSQL database, like Cassandra for high read/write servers.
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
Scalability: The database will be very large. 100b * 100k * 36000 ~ 1TB, it's very large for the storage. So we need to store data in Cassandra which is easier for delete operation for memory optimization. Database partition and sharing is also a way. Regarding to servers, we need to partition as well using load balance to route requests to each server. The deletion data is marked as Tombstone and then merge the database space.
Low latency: We need to return the result under 500ms so request low latency. We need to add cache for reading purpose. We need strong consistency which means whenever, there is write request, we need to write to cache and then write to database. Use TTL settings to expire cached data after period. We can also use event-based cache mechanism to update the data, sending all requests to message queue which can decouple.
consistency: we can have eventually consistency so we can use message queue to send updates request for caching.
fault tolerant: When the operation failed, we need to send the request again until successful so we can use message queue and process the event