Microservice - Spring: <3> Saga & Try-Confirm/Cancel

You can refer them from link: https://servicecomb.apache.org/docs/distributed_saga_3

Github from : https://seabird868.wixsite.com/kris-tech/post/microservice

1. Saga

Saga based on Event sourcing. You can implement with framework Eventuate (https://eventuate.io). I've already implement it and realize that:

• It is a complex implement, you need a CDC service, Kafka and follow a standard coding of this library.

• Because based on events, if an event can't consume, the remaining events will stuck on queue. you will wait to solve the current event like processing sequence. From me, it can hang your process.

2. TCC (Try-Confirm/Cancel)

You can design and code by your self with this flow. From me, I design coordinator with 2 tables 'tcc_coordinator' and 'tcc_participant' to keep status of each step.

Case: A request comes in order to create a new customer with initial balance in customer service, and it also records a first-transaction in payment service.

• Participants: Customer Service & Payment Service.

• Important: all requests of confirm and cancel need to be idempotent.

1. Phase Try:

• Create a coordinator in 'tcc_coordinator' table with 'TRYING' status, and Create a participant 'customer service' with status 'TRYING' in 'tcc_participant'.

  • Create a customer entity with status 'Reserved'

• Update the participant 'customer service' with status 'RESERVED' in 'tcc_participant' and Create a participant 'payment service' with status 'TRYING' in 'tcc_participant'

  • Call Payment service to create user's first-transaction with status 'Reserved'

• Update a participant 'payment service' with status 'RESERVED' in 'tcc_participant' and Update tcc_coordinator status = 'CONFIRMING'.

2. Phase Confirm:

• Update Customer's status to 'Created'

• Update tcc_participant of customer service with status 'CONFIRMED'

  • Call Payment service to update user's first-transaction with status 'Success'

• Update tcc_participant of payment service with status 'CONFIRMED' and update tcc_coordinator with status 'CONFIRMED'

• If any action in phase Confirm is fail, auto retry or manual intervention have to happen.

3. Phase Cancel: (Happen when any exception in Phase 1 or Timeout <=> tcc_coordinator status <> 'CONFIRMING')

• Update tcc_coordinator status = 'CANCELLING'

• Loop Participants:

  • Call the participant to abort-delete them.

  • Update tcc_participant status = 'CANCELED'

• Update tcc_coordinator status 'CANCELED'.

• If any action in phase Cancel is fail, auto retry or manual intervention have to happen.

Constants of status includes:

public static enum CoordinateStatus {TRYING,CONFIRMING, CONFIRMED,CANCELLING,CANCELED};
    public static enum ParticipantStatus{TRYING,RESERVED,CONFIRMED,CANCELED};
    public static enum FunctionName{CREATE_CUSTOMER}
    public static enum ParticipantId{CUSTOMER_SERVICE,PAYMENT_SERVICE}

3. Implement In Fact

• We don't need a coordinator table if your table is designed with status to check the current state or a temporary table to keep for confirm state.

• In confirm state, you can retry request by scheduler or retry with asynchronous with queue.