this assumptions done to speed up test task development
- better to split the Reservation model into Reservation and Task. Tasks should be a separate general-purpose service that handles tasks in an async way
- should be implemented auth
- implement backoffice to administrate available items/users
- omit implementing a scheduler which should free up items not in the FINISHED state
- run configs are done only for development/demo, added possibility to refactor configs to use the application in production
There are only 2 tests implemented for demo purposes. You can find them /reservation/tests/
Since there is no auth implemented anyone can add items. Upon launch will be added 3 demo items to DB. The application does not support adding items via UI.
when anyone adds an item to the card, the item becomes locked so no one else can reserve the item while waiting for external service to respond. After the external service responds item becomes reserved. In case of an external server error item will be released. NOTE: it is not implemented features to release locked items in case a background worker dies and/or fails to update the reservation status
- add auth(JWT) module
- add backoffice for administrators
- add clear up scheduler
- handle user errors
- increase test coverage
- navigate to project root
- execute:
docker compose up
- be API doc link: http://localhost:8000/doc/
To deploy this application to production, there is a need for the following resources:
- redis DB instance
- SQL DB instance
- one instance of celery workers/queue
- one instance to run the BE application