25 lines
1.3 KiB
Markdown
25 lines
1.3 KiB
Markdown
|
# 5. Event driven communication
|
||
|
|
|
||
|
|
Date: 2021-10-18
|
||
|
|
|
||
|
|
## Status
|
||
|
|
|
||
|
|
Accepted
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
The TAPAS system will be implemented following the Microservices architecture. Each service encapsulates a different bounded context with different functional and non-functional requirements. The TAPAS system could either be implemented as Synchronous Microservices or Event-Driven Microservices.
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
The TAPAS system could either be implemented as Event-Driven Microservices.
|
||
|
|
|
||
|
|
Event-driven asynchronous communication suits the TAPAS system better than synchronous communication. This will facilitate looser coupling between services.
|
||
|
|
|
||
|
|
Scalability, one of the system's top 3 driving architectural characteristics, will be positively impacted as individual services can be scaled up and down as needed.
|
||
|
|
|
||
|
|
Responsiveness (another of the system's driving architectural characteristics) will also improve as services do not need to wait for other services to respond before responding themselves.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
Asynchronous communication makes error handling more complex. At this moment in time we do not see this coming a problem. However, if the error handling becomes overly complex, then we might need to implement the workflow event pattern in order to combat this increased complexity.
|