chapter nine

9 Implementing system commands with sagas

 

This chapter covers

  • Why system commands must be transactional
  • Saga pattern fundamentals
  • How to design sagas to be ACID

The previous chapter described various inter-process communication (IPC) mechanisms. Those IPC mechanisms are not ends in themselves, but are used by higher-level service collaboration patterns that implement operations spanning multiple services. This chapter explores one of those patterns: the Saga pattern. The Saga pattern implements distributed system commands, which are operations that update data in multiple services - a common and challenging design problem in a microservice architecture.

This chapter begins by explaining why system commands must be transactional and why providing transactional guarantees becomes significantly more challenging once a command spans multiple services and databases. It then introduces the Saga pattern as the primary approach for implementing distributed system commands in a microservice architecture. It discusses the implications of a saga’s limited transactional guarantees and explains how application-level design techniques must replace capabilities that were previously provided by the database.

9.1 Transaction management in a microservice architecture

9.1.1 System commands need to be transactional

9.1.2 ACID transactions in a microservice architecture

9.2 Using the Saga pattern

9.2.1 An example saga: The Create Order saga

9.2.2 The structure of a saga

9.2.3 Overview of saga coordination

9.2.4 Benefits and drawbacks of sagas

9.3 Handling saga’s lack of isolation

9.3.1 Overview of anomalies

9.3.2 Countermeasures for handling the lack of isolation

9.4 Summary