Therefore, it is very important to create your own mind maps or any other means to conceptualize most of the concepts that this great framework offers. Once you get used to it, it may not be that difficult to remember.

As most of us do, I also went through the TOGAF information overloading. But I am happy to say that I am slowly getting the hang of it now. The best part of my learning was that I was able to apply to some of the projects that I have worked recently. That really helped me to practically grasp some of the key concepts that the framework tries to offer.

So, in this blog post, I am trying to visualize how the Architecture Roadmap is developed and how it is realized in a typical TOGAF ADM cycle. In this process some of the key deliverables are also highlighted.

Thank You! Happy learning.

(P. Note. Ministries in Sri Lanka are subject to change every year of so :)).

The study adopted the Open Group TOGAF as the base EA framework. For the IF development, it followed the European Interoperability Framework (EIF).

Leveraging the TOGAF BDAT Framework (BDAT = Business, Data, Application and Technology), the study managed to complete current architecture by covering 80% of government organizations. This gave the study the much-needed understanding of the current setting and the gaps involved.

The gaps were identified by comparing the target architecture proposed. In the target architecture, the primary target was to identify data owners based on the current scope of each organization (Single Source of Truth) . This process was able to identify most of the duplicated business processes, information systems and databases while identifying key registries.

I am sure, if the proposed architecture is implemented in the future, it will have a greater impact in terms of data sharing within the sector and beyond. Most importantly, it will be a good case study or a reference to other sectors in the Sri Lankan Government, which desperately need some sort of an integration. If not, Connected Government will be just a dream for us like it has been for decades.

You can reach both EA and IF for the Sri Lanka Agriculture Sector by following the below links.

1. Sri Lanka Government Agriculture Enterprise Architecture (SL-GAEA) — SL-GAEA_V1.3.pdf
2. Sri Lanka Government Agriculture Interoperability Framework (SL-GAIF) — Agri_IF_V1.3.pdf

Thank You!

Overview

As Enterprise Architects we have witnessed how enterprise software architectures have been evolved over the years.

The typical “operational plane” of a typical enterprise software architecture, evolved from a centralized monolithic design to a distributed microservices design. Now we are seeing the same paradigm shift slowly being adopted in the “data analytical plane” as well.

So, let's have a look at what it really means.

Enterprise Data Platforms

During the past few decades, we have been witnessing three (03) basic generations of enterprise data platforms.

1. Generation 01 —> Data Warehouses
2. Generation 02 —> Data Lakes / Lake houses
3. Generation 03 — -> Modern Cloud Data Architectures (The Hybrid Approach)

In the first era, companies invested heavily by moving the organization wise data to Data Warehouses for data retrieval / analytical purposes. In the next generation, they slowly moved the data workloads to more robust Data Lakes / Data Lakehouses replacing legacy Data Warehouses. However, slowly most of the modern data architectures introduced a hybrid model by having the best of both architectures (The warehouse and the lake). However, these modern data architectures have a centralized data approach where you collect and process your data in a central manner.

Though this approach made your life easier in terms of its ability to access your data in a more centralized manner, slowly it started to show some cracks. For example, data consumers can get overly dependent on a central data engineering team to get access probably to your own organizational data. On top of that, the data engineers who manage the central data repository (The warehouse or the lake) may not have the required business know-how to manipulate data consumer generated data. By looking at this, you can see that there is a clear problem of the ownership of the data.

The “data ownership” is a mandatory requirement for many regulatory institutions / ecosystems such as Governments, Banks, etc. With the advent of evolving “Data Protection Acts” in many regulatory environments (especially in the public or banking sectors), we cannot deny the importance of data ownership and its governance. Hence, adopting a more decentralized approach to your own data is slowly becoming a must.

Data Mesh

The “data mesh” is more of a “process” than a “technology stack or and implementation style”. It is basically a data architectural approach that delegates the responsibility of enterprise data to those areas of business that have the expertise in them.

In the “data mesh” approach, the data engineering team can easily break the entire data architecture into smaller, domain-oriented components (Data Products) allowing them to be more agile and scalable. This is exactly maps with what we do with microservices as well.

With the “data mesh” approach, a group of experts within a selected “domain” manage its datasets within the “domain”. They are responsible to build “data products” within that “domain”, which can be later consumed as APIs within the organization or outside the organization, depending on the sensitivity of the data.

The respective “domain” basically owns and controls the “data products” under its purview. These “data products” could be disseminated via APIs (i.e. REST) just like you do in a typical Microservices setup.

Data Mesh Principles

Zhamak Dehghani [2], who conceptualized the Data Mesh design, explains its architecture with four key principles.

1. Domain-driven decentralization
2. Data as a product
3. Self-service data platform
4. Federated governance

Domain-driven Decentralization — Data is owned by those who know it best. These domain teams basically own their data and will grant access by request.

Data as a product — Domain teams are responsible for the quality of data, unlike central data lakes had data pipelines to cleanse the data which are ingested. These domain level data are shared as a product to another domain if required. These data are discoverable, addressable, trustable, and secure. A “Data Product” is known as a “Node” in a Data Mesh Domain. For example, the “Farmer” domain has three Data Products / Nodes. (See the Agriculture Data Mesh example below). Each of this product can work as a “microservice for the data world”. Each Data Product is an encapsulated component, which comprises as a combination of (data + code + infrastructure).

Self-serve Data Platform — Data is available via centralized self-service platform.

Federated Data Governance — This principle is there to make sure all the autonomous data products under each domain are working together. This is established by having global standards such as data interoperability standards, that can apply to all data products in each domain in the data mesh. These are basically implemented and enforced centrally by the data mesh platform.

Is it a silver bullet?

Data Mesh is never a silver bullet like any other software architecture pattern. It is recommended for a more complex and larger data architectures, which needs some agility, data ownership, etc. If your data architecture is a smaller one, with a smaller number of domains, with a lesser regulatory background, then having a Data Mesh may be an over-kill considering the effort and its complexity. This is same as what we experience in a typical Microservices adoption.

Hope you were able to get a basic understanding about what “Data Mesh” is trying to achieve. There is more to it. Let's drill them down in later articles.

Thank You!

References

1. How to move beyond a Monolithic Data Lake to a Distributed Data Mesh — https://martinfowler.com/articles/data-monolith-to-mesh.html
2. Data Mesh: Delivering Data-Driven value at Scale [Book] — By Zhamak Dehghani
3. https://www.thoughtworks.com/en-us/insights/books/data-mesh

API Gateway Pattern

API Gateway Pattern: Implementing a service that is the entry point into a microservices based application from external API clients. [1]

Due to a lot of drawbacks with clients trying to access microservices directly via the Internet, it is recommended to apply the API Gateway pattern as a solution and a design pattern. It basically works as the entry point into a microservices application from the outside your system boundary.

This pattern is quite similar to the Facade Pattern in object orientation, which encapsulates the microservices application internal architecture and provides and API to its clients.

Some of the key responsibilities of the API Gateway Pattern are as follows:

1. Request Routing
2. API Composition
3. Edge Functions
4. Protocol Transformations

Out of four (04) responsibilities mentioned, both request routing and API compositions are the main key features of any API Gateway.

The third option, which is the Edge function can be helpful to utilize one of the following.

1 Authentication — Verifying the client identity

2. Authorization — Verifying the client is authorized to perform a particular API operation

3. Rate limiting — Limiting the incoming requests from clients

4. Caching — Caching the responses to reduce the number of incoming requests to the back-end service.

5 Matrix Collection — Collecting metrics on API usage

6. Request logging — Logging client requests

All these edge operations can be implemented at three different levels in your deployment architecture.

1. Back-end services level — [Less secure]
2. Edge service level — [This is to have a separate service layer for an Edge service. This is better than the first option, but requires an additional hop]
3. API Gateway level — [This requires less hops than the the second option and it is more secure and convenient to govern]

However, generally the API Gateway governance is taken care of by a separate API Gateway team and not by other individual API teams. This situation will definitely lead to governance conflicts.

Therefore, it is always good to separate the API Gateway governance by having separate API Gateway for each API / microservices team. This approach is known as Backends for Frontends (BFF) pattern.

Backends for Frontends (BFF) Pattern

BFF Pattern: Implement a separate API Gateway for each type of client.[1]

As you see on figure 02, there is a common API Gateway for all types of clients and on figure 03, there are separate API Gateways (micro) for all types of clients.

By having micro API Gateways for each client type, basically isolate the business logic at the API Gateway level for each client type based on certain API logic variations. This allows the reliability for each client type, just as you experience in a typical microservices back-ends.

As a live example, Netflix uses multiple API Gateways for its each client type to improve its scalability and performance.

Implementing an API Gateway

You can take multiple approaches for this.

1. Use a built-in API Gateway cloud based products in the market (AWS API Gateway, etc)
2. Use an Open Source built products (i.e. WSO2 API Gateway, Kong, Traefik, etc)
3. Building your own API Gateway using some existing open source frameworks such as Netflix Zuul or Spring Cloud Gateway. Out of these two, Spring Cloud Gateway is an API Gateway framework built on top of several frameworks such as Spring 5, Spring Boot 2, Spring Webflux and Project Reactor.

References

1. API Gateway Pattern: https://microservices.io/patterns/apigateway.html

Microservices Patterns Series — Part 07

In the typical microservices design, the Database per service pattern indicates that each microservice should be responsible for its own data. However, if the consumer wants to access data, which spans across multiple microservices, we should be able to find a solution for that. There are two data query patterns, which we can introduce here.

1. The API Composition Pattern [1]
2. The Command Query Responsibility Pattern (CQRS) [2]

Out of these two patterns, the API Composition Pattern is more simpler to use and adopt. Comparatively, The CQRS Pattern is more powerful and complex. In this blog, lets compare these two patterns in detail.

The API Composition Pattern

The API Composition Pattern: Implement a query that retrieves data from several services by querying each service via its API and combining the results. [1]

Structurally the API Composition Pattern deals with two key participants. (1. The API Composer 2. The Provider Services / Microservices).

The API Composer implements the query operation by querying the provider services.

The API Composer invokes all involved provider services and combines the results together with an in-memory join before presenting to the consumer.

In the API Composition pattern, these provider service invocations could happen in parallel or in sequence. For example, in figure 01, all three provider services (order, payment, deliver) should be called in sequence or in parallel (in a quick time) in order to get an output.

API Composition Pattern — Drawbacks

1. The overhead of invoking multiple service providers using multiple database queries can be time consuming. In such a situation, more computing and networking resources are required and that would add some additional cost as well to the application in general.
2. Having multiple service endpoints can be a hindrance to the overall availability of the application and increases the coupling with related service endpoints. There can be situations, where at least one failed service endpoint, which would result a less reliable system.
3. The data inconsistencies could be there in the API composer result due to the fact that, API composer does retrieve data from multiple external service providers. Each service provider can have data with inconsistencies attached to them. For example as in figure 01 example, if a consumer decides to cancel an already placed order, which the consumer had completed a few minutes ago, the Order microservices is now updated as a CANCELLED order. However, with eventual consistency around there could be a possibility that the Purchasing microservice is not yet updated with a payment cancellation, which could lead to an inconsistency of the final data query output via the API composer. In addition to that, sometimes certain service provider queries need data from other service providers to respond. In such situations, having data replicas in many service provider level databases are required. Maintaining multiple data replicas of other service providers could lead to data inconsistencies as well.
4. The inner joins, which are being used by the API composer can be quite confusing at times and difficult to apply.

CQRS (Command and Query Responsibility Segregation) Pattern

The CQRS Pattern: Implement a query that needs data from several services by using events to maintain a read only view that replicates data from the services

In order to overcome some of the drawbacks, which have been identified under the API Composition Pattern, the CQRS Pattern can be applied to many microservices based applications.

So, what can CQRS can do for us?

In simple terms, it is all about segregation or the separation of commands and queries. As you see in figure 02, CUD (Create, Update and Delete) operations are routed through the domain / command model and the R(Read) operations are routed through the query model.

Furthermore, the command model publishes domain events whenever its data changes to the query model as an eventual consistency transaction via an Event Bus.

With this approach, all the data queries pertaining to the given service is accommodated via the Query DB and will “not” be depending on the Command level DB anymore. This will certainly improve the performance and the scalability of the application.

Conclusion

Hope the above simple comparison will give you the importance of the CQRS method and its application primarily on a microservices architecture compared to the API composition pattern, which we mostly tend to implement.

Thank You!

References

1. API Composition Pattern: https://microservices.io/patterns/data/api-composition.html
2. CQRS Pattern: https://microservices.io/patterns/data/cqrs.html
3. Database per Service Pattern: https://microservices.io/patterns/data/database-per-service.html

Microservices Patterns Series — Part 06

In a typical traditional persistence model, we store the “current state” of an aggregate on a relational database table. If we are to track any events that happened around the aggregate, we will basically use transaction log files to store them. However, these transactional logs may not give you the complete picture of a transaction state. It will probably give you some high-level information related to it. So let's find out what Event Sourcing can offer you in this aspect.

Event Sourcing

Event Sourcing is a different way of structuring the business logic and persisting aggregates. It persists an aggregate as a sequence of events and each event represents a state change of the aggregate.

By doing this, it helps to preserve the history of aggregates, which is valuable for auditing and regulatory purposes. With this history, it will provide some valuable information related to all the events that occurred for each entity. This is a way better approach compared to the traditional transactional log method.

Event Store

In Event Sourcing, event aggregates are stored as a sequence of events in a database, which is known as an Event Store.

In this approach, applications can insert or retrieve aggregate events by their primary key. At any given point, the aggregate “current state” could be derived from the event store value for the particular aggregate. With this, you will have a less chance of loosing any valuable information related to the aggregate that you are concerned with.

Event Publishing

Once events are stored in an event store, these events could be published to an Event Broker for its subscribers to consume them further. You can use an Event Broker (i.e. Apache Kafka) to handle this situation (See Figure 01).

The above (Figure 01), is quite similar to the choreography-based saga transactional approach, which we discuss under Saga Pattern. In this, each microservice is subscribed to events published by other microservices, where there is no central orchestration.

Some of the key benefits of Event Sourcing are:

1. Can reliably publish events whenever the state of an aggregate changes
2. It can provide an audit log that is guaranteed to be accurate.
3. Stores the entire history of each aggregate allowing to be queried them at a later stage

However, there are some drawbacks as well:

1. Learning curve could be more than the traditional state handling. Moving from a traditional monolithic application to a more event-based microservices application could be a difficult proposition for a programmer or a designer
2. Handling multiple versions of an event-based application could be tricky. If an aggregate schema changes over time, you will probably need to have another event store version to store the new changes in the schema.
3. Deleting data could be tricky since event sourcing is there to preserve the history of aggregates.
4. Querying an event store could be challenging. The CQRS (Command and Query Responsibility Segregation) method is specifically used for this.

Conclusion

So it was a brief introduction to Event Sourcing in general. Hope you got some good insight into the Microservice Event Sourcing Pattern by reading this blog. You can find my other blogs related to Microservices Patterns and Concepts using the following links.

1. Microservices Patterns: Inter Process Communication
2. Microservices Patterns: The Circuit Breaker Pattern
3. Microservices Patterns: The Service Discovery Patterns
4. Microservices Patterns: The Saga Pattern
5. Microservices Patterns: Business Services Patterns

Thank You!

References

1. Microservices Patterns: with Examples in Java [Book] — By Chris Richardson, Manning Publications, 2018
2. Event Sourcing Pattern: https://microservices.io/patterns/data/event-sourcing.html
3. Event Sourcing (Martin Fowler) : https://www.youtube.com/watch?v=ck7t592bvBg
4. Many Meanings of Event Driven Architecture (Martin Fowler): https://www.youtube.com/watch?v=STKCRSUsyP0&t=202s
5. Building a CQRS event store with Amazon DynamoDB — https://aws.amazon.com/blogs/database/build-a-cqrs-event-store-with-amazon-dynamodb/

Further Reading:

• Microservices Monitoring: Cutting Engineering Costs and Saving Time
• 5 Microservices Challenges and Blindspots for Developers
• Testing Microservices - Trace Based Integration Testing Example
• OpenTelemetry: A full guide

Microservices Patterns: Event Sourcing was originally published in Cloud Native Daily on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building business logic/service for an enterprise application whether it is a monolithic or microservice has more similarities than differences. In both approaches, it will comprise classes such as services, entities, repositories, etc. However, you will find some distinct differences as well. In this blog, I will try to emphasize those differences in a conceptual manner by revisiting some of the core design patterns and principles built into each architecture.

So, let's start with Hexagonal Architecture and how it relates to the enterprise application business logic.

Hexagonal Architecture

Any business service in an enterprise application theoretically leverages the Hexagonal Architecture at its core.

The Hexagonal Architecture / Ports and Adapter Architecture is an architectural pattern used in software architecture design. It aims at creating loosely coupled application components that can be easily connected to their software environment by means of ports and adapters. (Wikipedia)

As you can see in Figure 01, the business service logic is the core of the Hexagonal architecture.

Domain Model Pattern

The traditional procedural Transactional Script Pattern is often a good way to implement “simple business logic”.

Transaction Script Pattern: Organize the business logic as a collection of procedural transaction scripts, one for each type of request.

But when implementing a “complex business logic”, you should consider using the Domain Model Pattern, which is basically using the Object Oriented Design (OOD).

Domain Model Pattern: Organize the business logic as an object model consisting of classes that have state and behavior [1].

Domain Driven Design (DDD)

However, the Domain Model Pattern works well with a typical monolithic application back-end, it has certain limitations in Microservice applications, which is basically covered by the Domain Driven Design (DDD).

DDD is a refinement of OOD and it is an approach for developing the complex back-end business logic.

When using DDD, each service has its own domain model, which avoids the problem of having a single unified domain model for the whole application.

Strategic Patterns vs Tactical Patterns

DDD comes up with multiple strategic and tactical patterns.

Two of the key strategic patterns are Subdomains and Bounded Contexts. These patterns are basically useful to decompose the business logic in an application.

According to Vaughn Vernon’s book of “Implementing Domain Driven Design” [5], The subdomains live in problem space and the bounded contexts in the solution space.

In other words, while bounded contexts help you to manage the complexity within an application, Subdomains help to structure and organize the different aspects of the business domain.

In practice, bounded contexts often align with a subdomain, but it is also possible to have multiple bounded contexts within a single subdomain or to have a bounded context that spans multiple subdomains.

In each bounded context, we can build teams who are specialized in the respective domains to govern. These teams are there to build artifacts, requirements, specifications and services for the given domain.

The tactical patterns are basically building blocks of the domain model that you define in your service. Some of these tactical design patterns are Entity, Value Object, Factory, Repository, Service and Aggregate.

In this blog, let's dive a bit deeper into the Aggregate Pattern and its usefulness in a typical microservices design.

Aggregate Pattern

Aggregator Pattern: Organizing a domain model as a collection of aggregates, each of which is a graph of objects that can be treated as a unit [1]

A “traditional domain model”, is a collection of classes and relationships among them. In this model, all of classes and relationships are interconnected and it is relatively hard to find boundaries of each business object, which is the key requirement in a complex microservices design. The Aggregate Pattern in DDD can help you to solve this problem.

In the Aggregate Pattern, as per the definition, structuring a domain model as a set of aggregations makes their boundaries explicit and easier to understand.

Each Aggregate has a Root Entity (Aggregate Root) and possibly one or more value objects.

However, that does not mean one Aggregate can have only one entity. You can have multiple entities within an aggregate. But the best practice is to have fine-grained services with a minimum number of entities within an Aggregate to improve the scalability of each transaction.

The Aggregate Root is the main entity that holds references to the other aggregates in the domain model and it is the only entity in the aggregate that can be used for a direct lookup. Components such as value objects within the aggregate will have object references with each other. In figure 02, you will see this and each referred aggregate primary key ids are stored in the main aggregate, which is Aggregate 01. This allows to have a more loosely coupled architecture within the domain model.

An aggregate is often loaded entirely from the database (to avoid any lazy loading). Even while it is being deleted, the aggregate removes all of its objects from the database within its boundary. In addition to that, it is easier to store them in NoSQL databases such as MongoDB.

In a nutshell, applying the DDD Aggregate Pattern will,

1. Modularize the domain model in the service
2. Eliminate the possibility of object references between services (In DDD, references between classes in different aggregates are in terms of primary key value rather than object references)
3. A transaction can only create or update a single aggregate. This allows the application to use the Saga Pattern to update multiple aggregates (I discussed Saga Pattern in detail in one of my previous blog articles)

Aggregate and Saga Patterns

A Saga orchestrates a sequence of local transactions within a sequence of (micro)services in order to maintain data consistency. Each local transaction is having an Aggregate mapped to it. (See Figure 03).

Aggregate vs Bounded Context

In technical theory, there is a bit of a misconception about the difference between a bounded context and an aggregate. Therefore, it is imperative to understand the difference between them and their association with microservices.

As explained earlier, a microservice could be explained by a bounded context or a domain. Each bounded context will have one or more aggregates.

Therefore, in practice, a microservice should not be smaller than an Aggregate and should not be bigger than a bounded context.

Domain Event Pattern

Conceptually domain events are published by aggregates whenever they get created and updated. An aggregate knows when its state changes and hence what event to publish.

These domain events are ultimately published as messages to a message broker such as Kafka.

Domain Event Pattern: An aggregate publishes a domain event when it is created and undergoes some other significant change [1].

Event Storming

There are a few strategies for identifying domain events. One popular strategy is Event Storming, which can be performed via a workshop sort of an arrangement to understand a complex domain with many events. The end result of such a workshop is an event-centric domain model with aggregates and events.

Conclusion

That’s it! Hope you got some good insight into Microservice Business Service Patterns and other related concepts by reading this blog. You can find my other blogs related to Microservices Patterns and Concepts using the following links:

1. Microservices Patterns: Inter Process Communication
2. Microservices Patterns: The Circuit Breaker Pattern
3. Microservices Patterns: The Service Discovery Patterns
4. Microservices Patterns: The Saga Pattern

Thank You!

References

1. Microservices Patterns: with Examples in Java [Book] — By Chris Richardson, Manning Publications, 2018
2. Domain Model Pattern: https://martinfowler.com/eaaCatalog/domainModel.html
3. Aggregate Pattern: https://microservices.io/patterns/data/aggregate.html
4. Domain Event Pattern: https://microservices.io/patterns/data/domain-event.html
5. Implementing Domain Driven Design [Book] — By Vaughn Vernon, Pearson, 2016

Further Reading:

• 5 Microservices Challenges and Blindspots for Developers
• Microservices Monitoring: Cutting Engineering Costs and Saving Time
• Testing Microservices - Trace Based Integration Testing Example
• Microservices or a monolith - which one are you?
• 7 Best Tracing Tools for Microservices
• Top 11 Tools for Microservices Backend Development in 2023

Microservices Patterns: Business Service Patterns was originally published in Cloud Native Daily on Medium, where people are continuing the conversation by highlighting and responding to this story.

Objective

Transaction handling is an integral part of any enterprise architecture. This allows for building proper data consistency across enterprise applications. As an Enterprise Architect, knowing how to handle transactions in a distributed architecture is essential.

This blog will give the reader some insights into ACID Transactions, 2PC Pattern and finally the Saga Pattern in detail. The primary objective is to give an overview of how Saga Pattern operates and how it can solve real-world distributed transactional issues.

The blog was written with some background reading on multiple literature resources mentioned under the References. If you really want to go into detail about this subject I highly recommend reading the book Microservices Patterns: with Examples in Java — By Chris Richardson [3].

ACID Transactions

In a traditional monolithic application, the system will create a local database transaction that works over multiple database tables. If any error occurs in between a transaction, it will be rolled back to its initial state. These transactions are known as ACID transactions (Atomicity, Consistency, Isolation, Durability). ACID transactions greatly ease the developer's task by having exclusive access to a particular database. You could see this in many monolithic application architectures, which have a simple way of handling transactions with a single database. In Figure 01, you could see how both the Customer and the Order tables are updated via a single atomic ACID transaction.

Distributed Transactions

Unlike single monolithic applications, distributed applications are dealing with multiple services. In such architectures, handling transactions could be a challenge.

Two-Phase Commit (2PC) is one of the distributed transaction strategies that we could apply.

Two-Phase Commit (2PC) Pattern

The 2PC Pattern is all about updating resources on multiple nodes in a single atomic operation.

In 2PC, it carries out an update in two phases (Figure 02).

1. Prepare: Each node, participating in the transaction, whether it is able to carry out an update in the second phase. Once each node is able to ensure it, the coordinator will be notified. If any of the nodes are unable to make it, the coordinator is notified to roll back releasing any locks they have with nodes.
2. Commit: Carrying out the update and completing the transaction.

2PC represents a synchronous strong consistency approach within a distributed transaction.

However, 2PC is not fully recommended for microservices-based applications due to its synchronous blocking. This protocol will need to block the required object that will be changed before the transaction completes. This prevents the relevant object from being used by a different transaction (deadlock situation) until the ongoing transaction is fully completed. This is not a good situation, especially in a modern-day application.

Furthermore, it is not supported by many modern-day message brokers such as RabitMQ and Apache Kafka. In addition to that, some of the popular databases such as MongoDB and Cassandra are also not supported.

The Saga Pattern

As explained above, your business logic can use ACID transactions within services. However, it must use Saga Pattern in order to maintain data consistency across services.

Pattern: Maintain data consistency across services using a sequence of local transactions that are coordinated using asynchronous messaging [2].

A Saga is a sequence of local transactions. Each local transaction updates the local database using the familiar ACID transaction frameworks and publishes an event to trigger the next local transaction in the Saga. If a local transaction fails, then the Saga executes a series of compensating transactions that undo the changes, which were completed by the preceding local transactions (Figure 03).

It is an asynchronous and eventually consistent transactional approach, which is quite analogous to a typical microservices application architecture, where a distributed transaction is fulfilled by a set of asynchronous transactions on related microservices.

An important benefit of the asynchronous nature of a Saga message is that it ensures that all steps of a Saga are executed, even if one or more of the Saga’s participants is temporarily unavailable. In addition to that, it can support long-lived transactions without blocking any other microservice or an object in the process.

However, Saga has its own weaknesses as well. Some of the key challenges are,

• The lack of isolation between Sagas.
• Rolling back changes when an error happens within a Saga.

Saga Coordination

Sagas can be implemented in “two ways” primarily based on the logic that coordinates the steps of the Saga.

1. Choreography based sagas
2. Orchestration based sagas

In a choreography based saga, a local transaction publishes events that trigger other participants to execute local transactions. In an orchestrated-based saga, a centralized saga orchestrator sends command messages to saga participants telling them to execute local transactions. [3].

Generally in practice, simple sagas can leverage the concept of choreography and for complex sagas, it is recommended to use the orchestrated version. [3]

Choreography based Sagas

In this approach, unlike orchestrator-based saga, there is no central coordinator to tell saga participants what to do. Saga participants subscribe to each other’s events and respond accordingly (Figure 04).

• Interaction Type: Publisher / Subscriber Messaging

In Figure 04, each saga participant (here it is the microservice) communicates with each other by exchanging events. In this diagram,

• Event Topic 1 is subscribed to Microservice 2 and 3
• Event Topic 2 is subscribed to Microservice 3
• Event Topic 3 is subscribed to Microservice 1 and 2

Each saga participant updates its local database and publishes an event that triggers the next participant. For example, in Figure 04, once microsrevice 01 completes its local database update, it publishes an event to Event Topic 1 in the message broker. Saga participants, which are subscribed to Event Topic 1 are now triggered to execute any other actions within the microservice and publish further events (if any) to connect with other saga participants. Likewise, the flow can continue until the saga is fully completed.

Simplicity and Loose coupling are some of the key benefits of using choreography-based sagas. However, choreography-based sagas are coupled with some significant drawbacks as well. Some of the key drawbacks are:

• Difficulty in understanding the flow — Generally this type distributes the implementation of the saga among the services. In this method, there is no centralized place for it to define the flow of the saga.
• Cyclic dependencies between services — Saga participants have the possibility of having cyclic dependencies such as microservice 01 -> microservice 02 -> microservice 01
• Risk of tight coupling -> Having to subscribe to all events that affect them could end up having a tight coupling among services.

Due to the above drawbacks and how it is being architect, it is advisable to say that choreography-based sagas are fine with a few services but with complex services setup.

Orchestration based sagas

In this type, a central Saga orchestration class is responsible to tell saga participants what to do.

• Interaction Type: Asynchronous Request/ Response

Here, an Asynchronous Request also names a “Command Message”

As you see in Figure 05, the “Saga Orchestrator” which is implemented within Microservice 01, initiates the saga transaction (e.g. Create Order Saga). As shown above, the interaction style is asynchronous request/ response and the request is forwarded as a “command message”. Since it uses the asynchronous request/ response style, it does use separate request and response channels within the message broker.

In Figure 05, when microservice 01 receives the create() request, it creates the saga orchestrator. This will set the service request to the PENDING state until the saga orchestrator gets the complete approval. Meantime, the saga orchestrator sends request commands to both microservice 2 and 3 and gets the responses back via the saga orchestrator response channel in the message broker. Based on the outcome of both responses, the orchestrator will approve or reject the request.

Some of the key benefits are,

• Simpler dependencies — Always orchestrator invokes saga participants not vice versa. Therefore, there are no cyclic dependencies.
• Less coupling — Unlike a choreography-based saga, it does not need to know about events published or the business logic implemented by other saga participants. This improves coupling and greatly simplifies the business logic.

There are a few drawbacks as well.

• Less business logic at the saga orchestrator level — Try not to have business logic within the saga orchestrator allowing to have more decoupled architecture. Having business logic outside of the relevant service is “not” recommended as it is advised not to load business logic in the saga orchestrator.
• Less Isolation — As a whole, microservices architecture lacks Isolation compared to traditional ACID transactions. This is due to the fact that saga participants do commit changes as local transactions before completing the whole transaction. As a result at the database level anomalies could happen.

Anomalies

There are three types of anomalies found in a typical saga.

1. Lost Updates — One saga overwrites an update made by another saga.
2. Dirty Reads — One saga reads data that is in the middle of being updated by another saga.
3. Fuzzy / Non-repeatable Reads — Two different sets of a saga read the same data and get different results because another saga has made updates.

Out of these three, lost update and dirty read scenarios are the most common.

In order to rectify the anomalies, it is required to implement countermeasures in your designs. There are multiple countermeasure approaches in the literature and some of the important ones are as follows.

1. Semantic Lock — This is an application-level lock, in which saga’s compensable transactions set a flag (e.g. Creating an Order can have flag status such as APPROVAL_PENDING, REVISION_PENDING, etc.) in any record that it creates or updates. This flag indicates that the record is not committed and that it has the potential to change. This could be cleared by a retriable transaction or a compensating transaction.
2. Commutative Updates — Designing the system to have more its update operations to be commutative (updates in an orderly manner). This can basically eliminate lost updates.
3. Pessimistic View — Reordering saga participants/services to minimize the effect of dirty reads.
4. Reread Values — This countermeasure reread values before updating it to further to re-verify the values are unchanged during the process. This will minimize lost updates.
5. By Value — This strategy will select concurrency mechanisms based on the business risk. This can help to execute low-risk requests using sagas and execute high-risk requests using distributed transactions.

Conclusion

That’s it! Hope you got some good insight into the Saga Pattern and other related concepts by reading this blog. You can find my other blogs related to Microservices Patterns and Concepts using the following links.

1. Microservices Patterns: Inter Process Communication
2. Microservices Patterns: The Circuit Breaker Pattern
3. Microservice Patterns: The Service Discovery Patterns

Happy coding!

References

1. Two-Phase Commit: https://martinfowler.com/articles/patterns-of-distributed-systems/two-phase-commit.html
2. The Saga Pattern: https://microservices.io/patterns/data/saga.html
3. Microservices Patterns: with Examples in Java [Book] — By Chris Richardson, Manning Publications, 2018

Further Reading:

• Microservices Monitoring: Cutting Engineering Costs and Saving Time
• Testing Microservices - Trace Based Integration Testing Example
• OpenTelemetry Tracing: Everything you need to know
• Top 11 Tools for Microservices Backend Development in 2023
• OpenTelemetry: A full guide

Microservices Patterns: The Saga Pattern was originally published in Cloud Native Daily on Medium, where people are continuing the conversation by highlighting and responding to this story.

Due to the dynamic nature of a microservices application, it is difficult to invoke a service with a fixed IP address of the service. This is where the concept Service Discovery comes into the picture. This will help the client to know where the service instance is located. In such a situation the Service Discovery component will act as a Service Registry.

A Service Registry is a centralized server / a database containing the location of service instances. In a microservices setup, services update their locations in the service registry at regular intervals. Then service consumers can connect to the service registry and fetch the locations of those services. Netflix Eureka is a popular “Application-Level” open-source Service Registry.

In service discovery, there are two types of patterns.

1. Client Side Service Discovery
2. Server Side Service Discovery

Client Side Service Discovery

Multiple steps are involved in this.

1. The locations of the Service Provider instances are added to the Service Registry (Self Registration Pattern).
2. When the Service Consumer wants to request for a particular service, the service discovery mechanism will query the Service Registry to obtain a list of available Service Provider instance locations.
3. The location list will be sent back to the Service Consumer after fetching it from the Service Registry.
4. Finally, the Service Consumer will route the service request to one of the Service Provider instances.

Self Registration Pattern

In the Self Registration Pattern, a service instance registers itself with the Service Registry (See Figure 01 — Step 01). This happens with the Service Registry on startup and unregistered on shutdown.

The service instance may invoke Service Registry’s registration API to register its network location. In addition to that, Service Registry invokes an API to the Service Provider instance for a health check.

Pattern 2: Server-Side Discovery Pattern

Instead of a Service Client querying the Service Registry, it makes a request to a DNS name, which resolves to a Platform Request Router that queries the Service Registry and Load Balances requests.

The key benefit of this pattern is, unlike the client-side discovery pattern, all aspects of service discovery are entirely handled by the deployment platform. This is a major advantage and a hassle-free approach for any development party. Deployment platforms such as Kubernetes (K8) has a built-in Service Registry and a service discovery mechanism to cover the Server Side Discovery Pattern.

The only limitation of this approach is, that you are a bit coupled to the deployment platform that you are using for the Service Registry. For example, if you using Kubernetes as the deployment platform, you are basically coupled to Kubernetes for the Service Discovery. If your other service components are also running on Kubernetes this will not be an issue. However, nowadays most of the deployments happen on cloud native Kubernetes containerized environments, this is not a major limitation.

Multiple steps are involved in this.

1. Service instances are registered with the Service Registry by the registrar (Third Party Registration Pattern).
2. The Service Client makes a request to the service network location from the Router and the Router queries the request from the Service Registry
3. Then the Router load balances the request from the available Service Provider instances.

Third-Party Registration Pattern

In the third-party registration (See Figure 02 — Step 02), instead of a self-registration with the service registry, a third party called the registrar handles the registration.

References

1. Client Side Discovery Pattern: https://microservices.io/patterns/client-side-discovery.html
2. Server Side Discovery Pattern: https://microservices.io/patterns/server-side-discovery.html
3. Spring Cloud Hystrix: https://howtodoinjava.com/spring-cloud/spring-hystrix-circuit-breaker-tutorial/
4. Kubernetes Service Discovery: https://www.densify.com/kubernetes-autoscaling/kubernetes-service-discovery/
5. https://www.baeldung.com/cs/service-discovery-microservices

Further Reading:

• Microservices Monitoring: Cutting Engineering Costs and Saving Time
• Testing Microservices - Trace Based Integration Testing Example
• 7 Best Tracing Tools for Microservices
• OpenTelemetry: A full guide
• Top 11 Tools for Microservices Backend Development in 2023
• Kubernetes Monitoring with OpenTelemetry

Microservices Patterns: Service Discovery Patterns was originally published in Cloud Native Daily on Medium, where people are continuing the conversation by highlighting and responding to this story.

Microservices Patterns Series — Part 02

The Circuit Breaker pattern is a basic pattern used especially in microservices based architectures.

The Problem

When one service synchronously invokes another, there is always a possibility that the other service is unavailable or unusable. This scenario could exhaust precious resources such on the caller side while waiting for the service to respond. This failure could cascade to other services throughout the application.

The Solution

The service client should invoke the remote service via a proxy that functions similar to to an electronic circuit breaker. It maintains a time out to minimize the client request load and handle service level errors efficiently.

1. When the number of consecutive failures crosses a threshold, the circuit breaker trips and stops responding client requests.
2. For the duration of a timeout period all attempts to invoke the remote service will fail immediately.
3. After the timeout expires the circuit breaker allows a limited number of test requests to pass through. If those requests succeed the circuit breaker will resume its normal operation.
4. Otherwise, if there is a failure the timeout period begins again.

When there is a service composition connected to the client proxy, it calls all services and aggregates their responses and sends the response to the client. The code that implement the client proxy endpoint should have a logic to handle the failure of each service it calls (Figure 05).

In a typical microservices deployment, containers are dynamic and has the tendency to go down at any given point. Therefore, this pattern implementation helps to prevent from sending unnecessary loads of requests to a failed service, by providing a delay to recover from errors.

References

1. Microservices Patterns: with Examples in Java [Book] — By Chris Richardson, Manning Publications, 2018
2. Circuit Breaker Pattern: https://microservices.io/patterns/reliability/circuit-breaker.html
3. Spring Cloud Hystrix: https://cloud.spring.io/spring-cloud-netflix/multi/multi__circuit_breaker_hystrix_clients.html
4. Hystrix Circuit Breaker Pattern: https://howtodoinjava.com/spring-cloud/spring-hystrix-circuit-breaker-tutorial/