22 lines
1.4 KiB
Markdown
22 lines
1.4 KiB
Markdown
# 7. Seperate service for Auction House
|
||
|
||
Date: 2021-11-21
|
||
|
||
## Status
|
||
|
||
Accepted
|
||
|
||
## Context
|
||
|
||
The auction house is the service that can connect to other groups’ auction houses. If there is a task whose task type does not match that of our executors, the auction house can start an auction where other groups can bid on doing the task for us. Moreover, it can also bid on other groups’ auctions.
|
||
|
||
## Decision
|
||
|
||
The auction house will be its own service.
|
||
The auction house is the only part of our system that has external communication; therefore, it makes sense to have it as its own service, also to guarantee better deployability.
|
||
The auction house does not scale directly based on the number of tasks, but only the proportion which needs external executors. Moreover, there could be limits on the number of auctions that could be started. Therefore, the auction house scales differently to other services.
|
||
Moreover, having the auction house as its own service also improves the fault tolerance of our system.
|
||
|
||
## Consequences
|
||
|
||
Since the auction house will be a standalone service, we have to make sure that if it goes down, it can recover its data in some way (which auctions it has launched, which auctions it has placed bids on or even won, etc.). Even though the testability and latency of our system might worsen by having a separate service for the auction house, we can implement different kinds of communication for internal and external communication in a much easier way. |