Synchronous Lookups

When you have a dedicated database for each microservice, if one service needs to access the data of the other, it can simply access the published API of that microservice and retrieve the required data. For example, as shown in Figure 5-6, the order service keeps the required product IDs that are part of a given order. If the Order Processing service requires the detailed information of the products, then from it’s application logic, it has to invoke the Product Management service and retrieve the product information.

This technique is quite trivial to understand and at the implementation level, you need to write extra logic to do an external service call. We need to keep in mind that, unlike databases, we no longer have the referential integrity of a foreign key constraint. This means that the service developers have to take care of the consistency of data that they put into the table. For example, when you create an order you need to make sure (possibly by calling the product service) that the products that are referred from that order actually exist in the PRODUCT table.

Using Asynchronous Events

Sharing data using synchronous lookups from other microservices may be expensive in certain business scenarios. As an alternative, we can leverage the event-driven architecture (publisher-subscriber pattern) to share data between services. For example, for the same scenario of the Order Processing and Product Management services (see Figure 5-7), we can introduce an event-driven communication pattern, in which we have an event bus, which is used as the messaging infrastructure. If there is an update to a product, the Product Management service (publisher) updates its product table and publishes an event into the event bus. The Order Processing service (subscriber) has subscribed to the interested topic of product updates and, therefore, as the Product Management service publishes product update events to that topic, the Order Processing service will receive them. Then it can update its local cache of product information and use the cache to implement the business logic of the Product Management service.

As the event bus you can select any asynchronous messaging technology (we discussed asynchronous messaging techniques in detail in Chapter 3, “Inter-Service Communication”), such as Kafka or AMQP Broker (such as RabbitMQ), and you can use different subscription techniques to ensure the delivery of the event to the subscriber (such as durable subscriptions).

With this approach, you can eliminate synchronous service calls from one service to the other, but since we are using a local cache, the data can be stale. Hence the asynchronous event-based data sharing is an eventual consistency model. Eventual consistency makes sure that the data of each service gets consistent eventually (you may get stale data for a certain amount of time). The time taken by the services to get consistent data may or may not be defined. Therefore, we need to use this pattern for use cases that are not affected by an eventual consistency nature.

Shared Static Data

When it comes to storing and sharing the immutable read-only metadata, conventional monolithic databases are often used and data is shared through a shared table. For example, data such as U.S. states, list of countries, etc., is often used as the shared static data. With a microservices approach, since we don’t want to share the databases, we need to think about how to keep the shared static data.

One would think that having another microservices with the static data would solve this problem, but it is overkill to have a service just to get some static information that does not change over time. Hence, sharing static data is often done with shared libraries. For example, if a given service wants to use the static metadata, it has to import the shared library into the service code.

Composite Services or Client-Side Mashups

When you have to create join of data from multiple microservices, you are only allowed to access the service APIs. So, to create composition of data from multiple microservices, you can create a composite service on top of the existing microservices. The composite service is responsible for invoking the downstream services and does the runtime composition of the data retrieved via service calls.

For example, let’s consider the example shown in Figure 5-8. Suppose that we need to create a composition of the orders placed and have the details of the customers who have placed those orders. Here we have two services—Order Processing and Customer—which have their own databases to hold the orders and customer information.

The requirement that we have at hand is to create a join of the orders and customers. With the composite service approach, we can create a new service—the Customer-Order composite service—and call the Order Processing and Customer microservices from it. You need to implement the runtime data composition logic as well as the communication logic (for example, to invoke RESTful Order Processing and Customer microservices) inside the composite service.

One other alternative is to implement the same runtime data composition at the client side. Basically, rather having a composite service, the consumers/client applications can call the required downstream services and build the composition themselves. This is often known as a client-side mashup.

Composite services or client-side mashups are suitable when the data that you have joined is relatively small. Since this is a runtime composition, if you are going to load a lot of data into memory, the runtime of the composite service will require a lot of memory. Therefore, we need to select this approach based on the data composition scenario that we have to implement.

Joins with Materialize View Using Asynchronous Events

There are certain data composition scenarios where you need to materialize the view with pre-joined data coming from multiple microservices. For example, consider the scenario illustrated in Figure 5-9. Here we have the Order Processing and Customer services, and we need to materialize the customer-order join/view. The materialized view will be used for a specific business function, which requires the join between orders and customers.

The Order Processing and Customer services publish order and customer update events to the event bus/broker. There is a service that has subscribed to those events and it then materializes the join of orders and customers. That service (Customer-Order-View-Sync) maintains a de-normalized join between the orders and customers, which is done ahead of time rather than in realtime. As shown in Figure 5-9, Customer-Order-View-Sync service also has a component that operates on the Customer-Order View Cache that serves all the external queries.

The denormalized data can be kept in a cache or other such storage and it could be consumed by another microservices as a read-only datastore.

Saga Log

The Saga log is a distributed log that’s used to persist every transaction/operation during the execution of a given Saga. At a high level, the Saga log contains various state-changing operations, such as Begin Saga, End Saga, Abort Saga, Begin T-i, End T-i, Begin C-i, and End C-i.

The Saga log is often implemented using a distributed log and systems such as Kafka are commonly used for the implementation.

Saga Execution Coordinator (SEC)

The SEC is the main component that orchestrates the entire logic and is responsible for the execution of the Saga. All the steps in a given Saga are recorded in the Saga log and the SEC writes and interprets the records of the Saga log. It also executes the sub-transactions/operations (e.g., invoke the hotel service and make a reservation) and the corresponding compensating transactions when necessary. While the steps related to the Saga are recorded in the Saga log, the orchestration logic (which can be represented as a directed acyclic graph) is part of the SEC process (orchestration can be built using your own custom logic or can be built on top of a standard, such as BPMN).

It is very important to understand that, unlike the coordinator in 2PC, SEC is not a special process that has central control of the entire execution. It certainly operates as a centralized runtime, but the runtime is dumb and the execution logic is kept in the distributed Saga log. However, it is required to make sure that SEC is up and running all the time. In the event of an SEC failure, a new SEC process should be started based on the same distributed Saga log.

Since now you have a good understanding of the SEC and the Saga log, let’s dive into the execution of a distributed Saga.

Executing a Distributed Saga

A distributed Saga is a Directed Acyclic Graph (DAG) and the SEC’s primary task is to execute that DAG. Suppose that, in our travel-booking scenario (see Figure 5-15), we have the SEC built into the travel agent service.

The SEC can start processing the Saga, which is recorded in the distributed log.

Once the travel agent service gets a travel-booking request, SEC initiates a Saga by writing to the Saga log with a Start Saga instruction along with any other metadata required to process the Saga. Once the record is durably committed into the log, SEC can move into the next instruction.

Then, based on the DAG of the Saga, SEC can pick one of the airline, hotel, or car rental transactions (given that all three can work in parallel). Suppose that airline transactions are executed first. In that case, the SEC logs a Start Airline message to the Saga log. Then, the SEC executes the book flight operation.

Once the SEC receives the response from the airline service, it commits the End Airline message along with the response from the airline service, which we may need during the latter part of the Saga.

Similarly, the same set of steps continues until we have successfully executed all three operations on the airline, hotel, and car rental services.

Finally, since we have completed everything successfully, SEC commits the End Saga message into the Saga log. This is a successful Saga execution.

Now let’s look at a Saga in a failure scenario. In Figure 5-16, we have the same set of steps that we discussed earlier, but in this case, the car rental process fails (imagine there are no cars available on the specified dates, for example).

Since we have detected a failure of a particular sub-transaction (i.e., the car reservation), we need to roll back all the other sub-transaction we made so far. So, in the Saga log you can find the Start Car Rental log and now the car reservation has failed. Now we have to walk through the inverted DAG of Saga that we executed so far and commit the rollback.

When the car rental service returns an error for the car reservation, the SEC commits the Abort Car Rental message to the Saga log.

Since this is a failure, the SEC has to initiate the rollback operations for the current Saga. The SEC can roll back the sub-transactions that are completed so far by inverting the DAG of this Saga and processing the Saga log backward.

So, the SEC looks for any records with car, hotel, and airline in the Saga log and it finds the records on the hotel and airline sub-transactions. The SEC will execute the compensating transactions for the hotel and airline. It can use the stored information on Saga logs, such as the reservation number, to execute the compensation transactions.

After a successful execution of the compensating transaction, the SEC commits the [Comp] Airline and [Comp] Hotel messages into the Saga log.

Finally, the SEC can commit the Saga completion into the Saga log.

SEC failures are relatively easier to handle, as we can recreate the DAG and the state by processing the Saga log. Also, in order for the Saga to function as expected, the sub-transaction should be sent at most once and the compensating transactions are sent at least once (idempotent).

It’s also important to keep in mind that at any given point in time, the system may not be in full consistent state, but with time it will come to a consistent state (eventual consistency). We execute the sub-transactions and complete them as we walk through the Saga DAG . But when we come across an issue, we roll back the transaction. In the example of an unsuccessful Saga, we booked the airline and hotel, and then later we cancelled both bookings.

The Saga pattern is not just for database transactions. The Saga concept is widely used in practice with solutions such as workflow, payment processing, financial systems, etc. Also, the Saga pattern is good for any use case that requires approval and human interaction.

The Saga pattern for microservices is supported in most workflow solutions that can operate in a microservices environment. In Chapter 7, “Integrating Microservices,” we explore how such workflow and business processes are used in the context of a microservices architecture.