Problem
Imagine you are building some sort of service that will be called by up to 1000 client applications to get simple end of day stock price information (open, close, high, low). You may assume that you already have the data, and you can store it in any format you wish. How would you design the client-facing service which provides the information to the client applications?
You are responsible for the development, rollout, and ongoing monitoring and maintenance of the feed. Describe the different methods you considered and why you would recommend your approach. Your service and use any technologies you wish, and can distribute the information to the client applications in any mechanism you choose.
Approach
From the statement of the problem, we want to focus on how we actually distribute the information to clients. We want to start off by thinking about what the different aspects we should consider in a given proposal are:
- Client Ease of Use: Service should be easy for the clients to implement.
- Ease for Ourselves: Service should be as easy as possible for us to implement. We need to consider in this not only the cost of implementing, but also the cost of maintenance.
- Flexibility for Future Demands: This problem is stated in a “what would you do in the real world” way, so we should think like we would in a real-world problem. Ideally, we do not want to overly constrain ourselves in the implementation, such that we can’t be flexible if the requirements or demands change.
- Scalability and Efficiency: We should be mindful of the efficiency of our solution, so as not to overly burden our service.
Simplest way is to request the information by stock symbol. However, it would be also useful to allow the client to use the company name to request stock information as well.
System should provide four values: open, close, high, low. It would be a good idea to just map both the company name and stock symbol to the stock information. One format will be keeping the data in Jason format as below:
{
"Open": 728.29,
"High" :718.29,
"Low" : 728.29,
"Close":728
}
As stated in the question, the service should serve up to 1000 clients. We should expect our service should be able to response to 1000 concurrent requests within the agreed response time. (Say, 1 second).
We could use a standard No SQL database, and let the clients plug directly into that. This would provide the following benefits:
- Facilitates an easy way for the clients to do query processing over the data, in case there are additional features we need to support. We could easily and efficiently perform a query such as “return all stocks having an open price greater than N and a closing price less than M.”
- Rolling back, back, backing up data, and security could be provided using standard database features.
- Reasonably easy for the clients to integrate into existing applications.
Below diagram shows a web service design. Reverse proxy/ load balancing server in front of the web server is to handle single point of faliure.
XML is another great option for distributing the information. Our data has fixed format and fixed size: company_name, open, high, low, closing price. The disadvantages using XML may include:
- This solution sends the clients all the information, even if they only want part of it. It is inefficient in that way.
- Performing any queries on the data requires parsing the entire file.