Open maestre3d opened 4 years ago
We could take advantage of Redis and Apache Kafka capabilities to design and build a nice distributed environment for declarative transaction execution,
Now considering using synchronous inter-service communication when a transaction is needed using resiliency patterns such as rate-limit for received requests and circuit breaker (w/ Netflix Hystrix) and a retry strategy for external calls (outbound) to avoid cascading failures and many more problems.
We would be still using asynchronous communication for side-effect distributed propagation.
This is due the complex implementation (e.g. dist. tracing and metrics for each event bus) and maintenance of each distributed transaction using pure events.
In addition, we could take advantage of event sourcing and CQRS when required to avoid these issues. More details here.
A well-tested approach is a Self-Contained service, more information about it here.
Thus, we will have two options and this kind of approach could be used whenever an operation must be tracked by the client.
This could be a definitive standard, almost closing this issue.
Describe the bug Whenever we start a distributed transaction (SAGAs mostly), the client is not able to see what is the current state in real-time and even worst, if something fails, there is no way to know what happened.
To Reproduce Steps to reproduce the behavior:
Expected behavior We must have a way to see entity's state in real-time while a distributed transaction is being executed along with following error information if a failing scenario happened.
Additional context No.