Loading...
User should be able to create a stock watch list and see active stock price
User should be able to add stock and remove stock from watchlist
User should be able to buy/sell stock in the system
User should be able to see a stock list with active price
User should be able to be able to match their order to the best price
10 hours market availability
user should be able to pay for their orders
Scalability handle large amount buy / sell request (60k / min) and have 1000 stocks available to trade
highly available
highly consistent
handle large amount buy / sell request (60k / min) and have 1000 stocks available to trade
addStockToList(stock_id)
removeStockFromList(stock_id)
buystock(stock_id, amount, price)
sellstock(stock_id, amount, price)
matchorders(buy_stock_request, sell_stock_request)
payment(user_di, request_id, amount)
addStockToList - API to add stock to watchlist
removeStockFromList - API to remove stock from watchlist
buystock - API to buy a stock(stock_id) for a price (default to current market price) and amount
sellstock - API to sell a stock(stock_id) for a price and amount
matchorders - API to match sell order and buy order and create a new execution order
payment - API for user to pay / receive money once order is placed
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...
OrderDB
id: string (PK)
user_id: string(FK)
stock_id: string(FK)
order_create_at: date
order_amount: long
price per unit: double
order_price: double
order_type: string
order_status: enum ( Success, Cancelled, Failed, Pending)
UserDB
user_id: string
email: string
password: long
StockDB
stock_id
stock meta data
OrderMatchDB
id: string(PK)
sell_order_id: string(FK)
buy_order_id: string(FK)
order_amount: long
order_price: double
StockWatchListDB
stock_id: list
user_ids: list
price: int
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...
The system will be a client server structure. The system contains three Services - OrderService, OrderMatchService and Execution Service
OrderService - once user sends a buy / sell request, the request will be sent to a buy / sell message queue. We can use AWS SQS to implement the queue. The service will also write an order record to the OrderDB.
OrderMatchService - This service will automatically find the best match for an order based on a priority ranking algorithm (the sell order will match to buy order with highest price and buy order will be matched to sell order with lowest price). Once orders are matched OrderMatchService will create an execution order and send to the execution queue, and write the matched order record to DB
ExecutionService - This service will interact with external stock exchange and payment service. The service will poll execution order from the queue and place the order. Once order is placed the execution service will deduce / add money to user balance / bank account and update database.
WatchListService - This service will actively poll stock price from exchange and push most updated price to users that are watching this stock with message queue
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...
For the order service and order match service, two groups of queues will be implemented. One for selling orders and one for buying orders. And in each group a queue for a specific stock (META, MSFT etc) will be implemented. So the Order Match service will have a node assigned for each stock and each node will only pulling request from that stock's queues.
While pulling the requests from queues, the order match service will check if a sell request can be matched to any buy requests. If a match is find the sell request and buy request will be removed from queue and formed into an execution request, the service will then push the execution request to the order execution queue which will later send the request to execution service.
Explain any trade offs you have made and why you made certain tech choices...
The system need to use SQL database to store orders to ensure data consistency
For the order queues we can use AWS SNS to ensure data privacy and other user won't see orders not related to them
Try to discuss as many failure scenarios/bottlenecks as possible.
The system might have a bottleneck that if the queue goes down, all pending orders will be lost. we can create a duplicate of the queues that stores the same information and do same polling and push. Once the production queue goes down we can use backup queue.
The order service might have bottleneck of scaling issue. We need to make sure we have enough servers in the service and each server only stores order information for certain list of stocks. And the queues will update the order information by publishing to specific topics.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?