CODEWITHSUNDEEP
spring-bootmicroservicessaga
WeiTang Lau
WeiTang Lau

Reputation: 123

Saga Pattern on hardware failure and inter services communication

I am building a Spring Boot microservice application. I am planning on adopting the Saga pattern to tackle the distributed transaction problem. Below is the list of questions and problems that I am facing.

Here is the context for ease of explanation.

Client -> Service A -> Service B

  1. Handling of non-alive microservices due to failure
    • Assuming that Service B is not alive due to hardware / software failure, how should A react?
  2. Async communication
    • It is recommended that we have async communication for saga pattern. Assuming that time for client -> A < A -> B, how does the Client receive the data that A receives from B at a later time? Is it that A has to return an Async object back to client? Something like CompletableFuture class?
  3. Service requesting resources from other services.
    • Assuming that Service A has to request some resources from Service B, how should A go about doing this? All I can think of is using HTTP / gRPC (eliminated communication from message broker).
  4. If you happened to have some experience / advice, please share :)

Any help or advice on Saga pattern is appreciated!

Upvotes: 1

Views: 880

Answers (1)

xs2tarunkukreja
xs2tarunkukreja

Reputation: 462

SAGA is used for distributed transaction. It can be implemented by using Orchestration or Choreography based. It is mostly (prefer) implemented by using async way of communication. Message Broker plays important role here.

There are lots of queries. Let me try to answer those.

  1. If one service is down - You can setup a monitoring system for SAGA. In case, if any service is down or SAGA is not processed for some threshold time then you can raise alert.
  2. Async Communication - It is mostly used to process some commands (not query). Whenever client call service A, it initiate the SAGA and reply back with current status. It also return a id (you can say job id). Now there are 2 ways through which Client get updated status. One is Poll (where client ask for status update after N sec) and 2nd is Push (where server push the changes when there is change in state.)
  3. Service request resource from other - Yeah, prefer way is REST or gRPC. Also, if data is type of constant then you can use cache.

Suggestion - SRE (Monitoring etc.) play an important role in Microservice architecture. So, if you have setup that well then you can easily handle other challenges of microservice.

Upvotes: 3

Related Questions