Skip to content

Latest commit

 

History

History
29 lines (16 loc) · 3.8 KB

solution.md

File metadata and controls

29 lines (16 loc) · 3.8 KB

[in progress]

Documentation, for the Solution

The purpose of this document is to provide an explanation of the choices and assumptions made during the development of the order placement API well as to suggest potential enhancements for future iterations.

##. Assumptions

  1. FastAPI; The decision was made to utilize FastAPI, which's an efficient web framework designed for creating APIs with Python 3.7+. FastAPI was selected due to its user interface, impressive performance and comprehensive support for data validation, serialization and documentation.

  2. SQLModel & PostgreSQL; SQLModel was employed for defining the data models while PostgreSQL was chosen as the database solution. By using Python type annotations SQLModel provides an approach to working with databases. PostgreSQL emerged as the preferred option due, to its reliability, maturity and optimal performance.

  3. Celery & RabbitMQ; To ensure an order placement process, Celery and RabbitMQ were employed. This strategic decision enables the API to promptly respond upon receiving a request while processing the order placement in the background. The decision to use RabbitMQ as the message broker was based on its robustness, scalability and compatibility, with Celery.

Possible Enhancements

  1. Improved Error Handling: Previously, if there was an issue with the stock exchange system, the order placement process could fail without providing any meaningful feedback to users or administrators. However, as part of our enhancements, we have successfully implemented a robust error handling mechanism that incorporates automatic retries for failed orders. Now, in the event of a transient failure during order placement, the system will automatically attempt to retry the process for a certain number of times, increasing the likelihood of successful order placement. This proactive approach not only increases the reliability of the application but also ensures that administrators are promptly notified if any critical issues persist. With these improvements, the application maintains better resilience and provides more insights into any potential issues during the order placement process.

  2. Enhanced Testing; Although basic unit tests have been implemented there is room for improvement, in the testing suite. Integration tests could be added to ensure that all components of the application are functioning together as expected. Additionally load tests could help identify any performance issues.

  3. Monitoring & Logging; For a production environment it is crucial to have a monitoring and logging system in place. This would involve tracking task status and completion time logging errors and important events as monitoring system health and performance.

  4. Security; It's important to note that this solution assumes usage in a trusted environment and therefore does not incorporate authentication or authorization mechanisms. In a real world scenario it is important to implement the security measures to safeguard data and ensure that only authorized users can make orders.

  5. Scalability; Although FastAPI, PostgreSQL and Celery/RabbitMQ are capable of handling loads in a situation, with traffic it may be advantageous to consider additional scalability measures. These could include techniques like database sharding deploying the application in a distributed manner or utilizing load balancing methods.

This solution serves as a foundation for an API that facilitates order placement. However there are opportunities for expansion and improvement to better meet needs in different use cases and environments. It's also crucial to keep in mind that this solution does not encompass aspects for a production ready application – such as comprehensive error handling, extensive testing, monitoring and logging facilities as well, as robust security protocols.