Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
add stock
stock low notification
order create
check stock amount
do payment
List non-functional requirements for the system...
low latency
reliability
consistency
scalable
real-time inventory which means we should use websocket to keep connection during the session.
Estimate the scale of the system you are going to design...
1Million user total
about 20% user will use the system daily
each user will call 100 request daily
QPS = 1Million * 0.2 * 100 / 86400 > 200
assume 60% requests are related to transaction
TPS > 120
each inventory information should be 10MB include image, text, video
each user will create 10 item
total storage = 1Million * 10 * 10MB = 100TB
Define what APIs are expected from the system...
add stock
input: stockId, amount, userId, price
output: success / failed
stock low notification
input: userid, stockid, amount
output: success / failed
order create (generate order and send it to payment module to do payment)
input: buyerId, stockId, amount, retailPrice, totalPrice
output: orderID
check stock amount
input: stockId
output: stock amount
do payment
input: orderId, cardinformation(json, encrypt)
output: paymentId
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
we should store item information, user information and payment information, because those have relation between each other, we use relational database to store
Item table {
stockId(primary key)
stock name
stock amount
stock price
}
user table {
userId(primary key)
user name
user password(hashing)
}
order table {
orderId(primary key)
stockId(foreign key)
userId(foreign key)
status(processing, complete, failed)
paymentId(foreign key)
amount
total price
}
payment table {
paymentId(primary key)
total price
card info(not sensitive)
}
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
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...
API Gateway is used to validate the user, avoiding the possible website attack and do rate limiter if needed
We push stock information to CDN to speed up the search stock process.
Explain any trade offs you have made and why you made certain tech choices...
we can devide database into read replica and write master database using the master-slave mode to speed up the reading and writing process for database
database should do partitioning and sharding to store large amount of data. They can do it by the combination of the userId and stockId(consistent hash userId and stockId)
The stock information pushed to CDN is different based on region. Becuase different region user may have different priority of the stock type
Try to discuss as many failure scenarios/bottlenecks as possible.
single point of failure:
inorder to avoid server or database failure, we will set replica for each of them so if one server down the replica can keep working without influance the system.
security:
card information like card number, cardholder name are sensitive information and should be encrypt before transmit
real-time inventory upates
we will use websocket to achieve the real-time inventory updates to make sure accurate updates。
another way to implement is long-polling but it is not real-time so we will keep with websocket
duplication order create/ dupliction payment
we can avoid duplication order create or duplication payment by checking the database order status, if it exist and processing, which means the payment and order has been created, which will avoid duplication
concurrency stock update
we can use OCC optimistic concurrency control to avoid consurency stock conflict. There also another way PCC but PCC need to add lock to system, which will influance the system efficiency.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?