27 lines
2.0 KiB
Markdown
27 lines
2.0 KiB
Markdown
|
# 3. Separate service for the Roster
|
||
|
|
|
||
|
|
Date: 2021-11-21
|
||
|
|
|
||
|
|
## Status
|
||
|
|
|
||
|
|
Accepted
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
The Task domain includes the creation and deletion of tasks from the system. It also stores all tasks and keeps track of a task's status. The Roster domain keeps track of internal task execution. It receives tasks from the Task domain. If the task can be executed internally then it queues it and keeps track of it until it has been executed by an internal executor. If it cannot be executed internally then it sends the task on to the Auction domain. These two domains could be implemented as a consolidated service or as two separate services.
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
We will create two separate services; a Task List service and a Roster service.
|
||
|
|
|
||
|
|
Firstly, having two separate services will improve the system's fault tolerance. If the Task List goes down then the Roster can keep on managing the internal execution of tasks. Similarly, if the Roster goes down then the Task List can keep on being receiving input from users. Since we use asynchronous messaging for internal communication, the services can process new events when they come back up. The creation and execution of tasks is the heartbeat of the TAPAS system. Therefore, making it more fault tolerant is critical.
|
||
|
|
|
||
|
|
|
||
|
|
Secondly, we don't expect the Task List to change as frequently as the Roster. The Task List usually just needs to change when there are large new features that will impact more than just the Task domain. These large changes will be not very frequent. Conversely, we expect the Roster to change more frequently due to changes in the assignment algorithm, communication with executors, or error handling.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
Before deleting a task from the Task List we first need to delete it from the Roster (and make sure it is not being executed). Having these as two separate services makes this transaction more complicated to manage.
|
||
|
|
|
||
|
|
Moreover, the services have to talk a lot to each other and having them seperated will add latency between them.
|