HSG-MCS-HS21_tapas/TAPAS-Final/doc/architecture/decisions/0006-separate-service-for-auction-house.md
2021-12-23 07:15:07 +00:00

2.4 KiB

7. Separate service for Auction House

Date: 2021-11-21

Status

Accepted

Context

The Auction House has to launch auctions and manage auctions for tasks that we cannot execute internally. Moreover, it has to subscribe to other Auction Houses and bid on their auctions. The Roster keeps track of tasks that need to be executed and assigns Executors to tasks. Additionally, the Roster passes tasks that cannot be executed internally onto the Auction House. The Auction House functionality can either be implemented as a separate service or as a part of the Roster.

Decision

The Auction House will be implemented as a separate service.

Most importantly, the Auction House and the Roster need to scale differently. The Roster needs to scale depending on the number of tasks in the system as all tasks go through the Roster initially. We predict that the majority of tasks will be executed internally. The Auction House also needs to scale depending on the number of external auctions. Moreover, the Auction House has different throughput as the Auction House has to communicate synchronously with a number of external clients.

Furthermore, separating the Auction House from the Roster will allow us to isolate the Roster from external communication. This improves the security of the TAPAS system as the Roster is more critical to the functioning of the system than the Auction House. Opening the Roster up to external communication could for example expose it to denial of service attacks.

Similarly, having two services separate will improve fault tolerance as either can fail without taking down the other. This is more important for the Roster as it can keep the main workflow of executing tasks going if the Auction House goes down.

Consequences

Latency is added to the communication between the two domains. However, this should not have a major impact on the overall functioning of the system.

Data needs to be duplicated since both services need to keep track of the executors available in our system.

Deleting of tasks becomes an even more complex transaction as now we also need to check the Auction House to see if the task is being auctioned before deleting (we don't want to delete a task that another group will then go on to execute). This transaction now involves three services (the Task List, the Roster, and the Auction House). We will most likely need to implement a saga pattern to manage this transaction properly.