# 9.1. Stock data

> You are building a service that will be called by up to 1k client applications to get end-of-day stock price information (open, close, high, low). Assume you already have the data, and you can store it in any format you wish. Design the client-facing service that provides the info to client applications. Design the development, rollout, and ongoing monitoring and maintenance.

The service is not ongoing so it will be called by different clients I assume. There are 4 parameters per stock, and I already have all the data and it is stored in a way that is efficient to search. The database should have fast lookup, and new additions can take time. Because the system should be scalable, many queries might be made and there are many stocks, NoSQL databases are preferred. MongoDB for instance.

The client will see a list of stocks, or can search their own stock. Then the front-end module will send a request to the database in the back-end, it will search the stock's information in the db, and will return these 4 parameters to the front-end. Then they are displayed in an infographic with the opening value, highest value, lowest and closing value.

For maintenance, there will be 2 queries to the stock market. At opening time, to get the opening value for the stock. And at the end time, to obtain the end value, high and low. In the simplest version, if the client makes a request in the middle of the day, they will only see the opening value. In a more sophisticated scenario, each time a client selects a stock, regardless of time, a query will be done to the stock market for the high, low and last value for that specific time, that data will be saved in the db and the information shown to the client.

For security, the clients can only have the possibility to query a stock, and the four parameters are already given to them.

## Solution

Mentions using a SQL database, but it is much heavier than the requirements and it needs an additional layer to view and maintain data, which increases the implementation costs. Clients should not have access to additional information. If they make expensive and ineffective queries, our db might bear the costs of that.

Another approach is XML, saving stocks, date and their 4 parameters in xml. It's easy to distribute, easily read by machines and humans, most languages have a library to perform XML parsing so clients can implement it easily. It is easy to add new data. But this solution sends the clients **all** information, even if they want part of it. And performing queries on the data means parsing the entire file.