Microservice architecture has become a widely adopted approach for building scalable and maintainable systems. However, one of the most complex decisions when implementing this architecture is defining the scope of each microservice. Should you split functionalities into separate services or keep them together? The answer lies in balancing what I call _integrators_ and _disintegrators_—factors that either encourage combining functionalities or suggest splitting them into distinct services.

In this blog post, I’ll break down how these integrators and disintegrators guide the microservice design process and help define the right boundaries.

## **The Role of Integrators and Disintegrators**

In this context:

- **Integrators**: Factors that suggest combining functionalities within a single service.

- **Disintegrators**: Factors that push you to separate functionalities into distinct services.

Balancing these factors ensures your microservices are scalable, maintainable, and resilient.

## **Disintegrators: When to Split Functionalities**

1. **Code Volatility** If certain functionalities change frequently and independently from others, it’s better to split them. This allows you to update one service without affecting others, reducing the risk of deploying changes.

2. **Access Control** Services with different access control requirements should be separated. Trying to enforce varying levels of security and permissions within a single service can lead to complex and error-prone configurations.

3. **Cohesion** High cohesion is critical for service maintainability. If different functionalities within a service are not tightly related in purpose, splitting them reduces unnecessary complexity and improves service focus.

4. **Fault Tolerance** If a failure in one part of a system should not cause the entire service to fail, separating functionalities ensures better fault isolation. This approach improves overall resilience by containing failures within specific services.

5. **Scalability** Different components often have unique scaling requirements. Splitting services based on how they scale individually allows for more efficient resource utilization and better performance.

## **Integrators: When to Combine Functionalities**

1. **Data Dependencies** When multiple functionalities rely on the same data model or require tight data consistency, combining them within a single service avoids complex distributed transactions and synchronization issues. Domain driven design helps to determie right bounded context of your domain, which is a huge factor in the microservice scope definition.

2. **Workflow** Complex workflows that involve multiple tightly coupled steps are better managed within the same service. Splitting them across multiple services could lead to unnecessary inter-service communication and increased latency.

3. **Database Transactions** Distributed transactions across services are often a red flag in microservice design. If certain operations require atomic transactions, it’s generally more efficient to keep them within a single service, simplifying both design and implementation.

## **Conclusion**

Designing microservices is a balancing act. While disintegrators encourage splitting functionalities for better autonomy and flexibility, integrators highlight cases where combining functionalities can simplify data consistency, workflows, and transactions.

There are no one-size-fits-all rules for defining microservice scope, but by analyzing the integrators and disintegrators relevant to your domain, you can design services that are well-scoped and aligned with both business needs and technical goals.

Ultimately, the key lies in understanding your domain deeply and making pragmatic decisions about service boundaries. With the right balance, you can create a microservice architecture that is both flexible and sustainable.

Defining Microservice Scope - Integrators and Disintegrators

The [modular monolith](https://www.buzzchart.info/post/modular-monolith) architecture isn’t new, but it’s become more popular as a way to balance the simplicity of a monolithic application with the flexibility of microservices. It promises to be the best of both worlds—until it isn’t. If you’re not careful, your [modular monolith](https://www.buzzchart.info/post/modular-monolith) can quickly become just as tangled and unmanageable as a traditional monolith. Here are five common pitfalls that can lead you down that path and how you can steer clear of them.

### **1. Forgetting to Enforce Boundaries**

It is easy to violate module boundaries, if there is no tooling in place to enforce it. Module boundaries must be preserved at all logical and physical layers of an application. Module “Book” cannot make an SQL JOIN in the persistance layer and join table customer. This is violation of module boundaries on a database level. The same rule must be applied to all “module” layers. For “Book” module cannot reference “Order” service directly. As a result you will end up with [tightly coupled](https://www.buzzchart.info/post/coupling-and-cohesion) modules, which loses the benefits of this architectural style.

How to Avoid This:

- Communicate through an module API, instead of directly referencing services and data structures from different modules.

- If you have all code in one repository tools like “ts-arch” for TypeScript project may help to define rules, which can be enforced on the CI.

### **2. Incorrect Module Boundaries**

A [modular monolith](https://www.buzzchart.info/post/modular-monolith) depends on clear boundaries between modules. These boundaries ensure that each module is self-contained, with its own logic and data. But what happens if you let those boundaries blur? You get [tightly coupled](https://www.buzzchart.info/post/coupling-and-cohesion) modules that depend on each other’s internals, making your application fragile and hard to maintain.

**How to Avoid This:**

- **Clear Interfaces:** Define and stick to clear interfaces for each module. This is non-negotiable.

- **Boundary Enforcement:** Use tools and rigorous code reviews to ensure that modules don’t cross into each other’s territory.

### **3. Overengineering Modules**

In an effort to make each module independent, you might be tempted to overengineer. Each module ends up being its own mini-application, complete with separate infrastructure, communication patterns, and even data storage. Sounds robust? It’s actually a recipe for complexity that can slow down development and integration.

**How to Avoid This:**

- **Balance Independence:** Your modules should be independent enough to be developed in isolation, but not so independent that they duplicate effort or infrastructure.

- **Avoid Premature Optimization:** Don’t overcomplicate things by trying to predict every possible future need. Build for what you need now, and adapt as necessary.

- **Lack of communication:** Development in application modules creates knowledge silos, because teams have different goals/tasks and have no incentive to align decisions.

### **3. Lack of Cross-Team Communication**

When different teams work on different modules without proper communication, you end up with a fractured system. Inconsistent implementations and duplicated logic are just the beginning. The lack of alignment makes integration difficult and increases maintenance costs.

**How to Avoid This:**

- **Encourage Collaboration:** Regular communication between teams is essential to keep everyone aligned.

- **Shared Documentation:** Maintain shared documentation on common practices, data models, and coding standards.

- **Cross-Module Reviews:** Implement cross-module code reviews to ensure consistency across the system.

- **Community of Practice**: Community of Practice tackles the knowledge silo problem. Where each team (maintaining n+1 modules) has its own practicies. To have common practicies you need to communicate and apply those practicies. This is why CoP is vital in the scope of a Modula Monolith. This is an organizational problem, which is hard to be solved with an techical means.

### **4. Ignoring Domain-Driven Design (DDD)**

Domain-Driven Design ([DDD](https://www.buzzchart.info/post/domain-driven-design)) is key to aligning your modules with your business capabilities. But if you ignore [DDD](https://www.buzzchart.info/post/domain-driven-design) principles, your modules may not map to actual business needs, making them harder to understand and evolve over time. If applicable module boundaries are implemented at the start of architecture, then it will be very hard to evolve application. You will end up with either to grannular modules, which will not be self sufficent, or with too fat modules, which will loose benefits of [modular monolith](https://www.buzzchart.info/post/modular-monolith).

**How to Avoid This:**

- **Embrace DDD:** Use [DDD](https://www.buzzchart.info/post/domain-driven-design) to guide the design of your modules, ensuring they align with business domains.

- **Focus on Business Capabilities:** Each module should represent a specific business capability. If it doesn’t, reconsider your design.

- **Bounded Contexts:** Clearly define bounded contexts so that each module has a well-defined responsibility and doesn’t overlap with others.

### **5. No Comprehensive Testing Strategy**

Testing is crucial, even in a [modular monolith](https://www.buzzchart.info/post/modular-monolith). Without a solid testing strategy, you might find that your modules don’t play well together, leading to unexpected bugs in production. Relying only on unit tests or skipping integration tests? That’s asking for trouble.

**How to Avoid This:**

- **Layered Testing:** Use a mix of unit, integration, and end-to-end tests to cover all bases in the modules.

- **Test Module APIs:** You need to test module API and better to develop htis API practicing TDD. Then you will not have APIs that are not used or bloated APIs.

- **CDC**: Consumer driven Contracts, are tests defined by a consumer. This allows Provider of a public API to know what API is used and how it is used. It allows to avoid breaking changes.

### **Conclusion**

Building a [modular monolith](https://www.buzzchart.info/post/modular-monolith) can offer a great balance between simplicity and flexibility, but it’s easy to fall into traps that can make it as unmanageable as a traditional monolith. To avoid this, enforce clear module boundaries, define modules correctly, avoid overengineering, encourage cross-team communication, follow Domain-Driven Design (DDD) principles, and implement a solid testing strategy.

By keeping these key points in mind, you can successfully leverage the [modular monolith](https://www.buzzchart.info/post/modular-monolith) architecture, achieving scalability and maintainability without the complexity often associated with microservices.

5 Ways to Fail at Implementing a modular monolith

**Understanding the Modular Monolith Architecture: A Balanced Approach**

A **Modular Monolith** is an architectural style that structures your application into distinct, well-defined modules within a single codebase. It combines the simplicity and performance of a monolithic design with the maintainability benefits of modularization. Each module is responsible for a specific domain, making it easier to develop, test, and maintain. However, as the application grows, scaling and managing dependencies can become more challenging compared to microservices.

**Pros:**

- **Maintainability:** Clear module boundaries improve code organization.

- **Performance:** Fewer inter-service communications lead to better performance.

- **Deployment:** Simplified deployment process since it's a single application.

**Cons:**

- **Scalability:** Scaling becomes harder as the app grows.

- **Complexity:** Managing module dependencies can get tricky over time.

**Architecture Ratings:**

- Maintainability: ⭐⭐⭐⭐

- Scalability: ⭐⭐

- Performance: ⭐⭐⭐⭐

- Deployment Simplicity: ⭐⭐⭐⭐

- Flexibility: ⭐⭐⭐

**Best Fit For:**

- **Ideal for:** Medium-sized applications like ERP systems or e-commerce platforms.

- **Not ideal for:** Highly scalable apps like large social networks or global streaming services.

Modular Monolith

Breaking changes is a result of a code changes, that how the API behaves. It can be low level code API, REST API, any microservice API or even user interface behavior.

Breaking changes can be of two types: structural and semantic.

## **Structural Breaking Changes**

Structural changes appears when the structure (contract) of an API changed. Changes can be in any code structural element. This is the list of structural breaking changes groups:

- remove parameter

- add parameter

- change parameter type

- change return type

- add required constructor

- make attribute required

- add type required restriction (also called generic)

Let's explore a **`lodash`** popular utils library in JavaScript ecosystem. In a [changelog](https://github.com/lodash/lodash/wiki/Changelog) we can find breaking changes in a version 3.0.0. When semver major version changes, it indicates, that API contains breaking changes.

```javascript
var wrapped = _([1, 2, 3]);

// in 2.4.1
wrapped.forEach(function(n) { console.log(n); });
// ➜ logs each value from left to right and returns the lodash wrapper

// in 3.0.0
wrapped.forEach(function(n) { console.log(n); });
// ➜ returns the lodash wrapper without logging until `value` is called
wrapped.forEach(function(n) { console.log(n); }).value();
// ➜ logs each value from left to right and returns the array
```

This example depicts the structural breaking changes, where the return type of function changed. In version 2.x this function was calling **`forEach`** eagerly. In version 3.x **`lodash`** made this function lazy, and returns wrapper instead of **`void`**.

## **Semantic Breaking Changes**

Semantic changes appears when output or side effect of API changed/added/removed. This is the list of semantic breaking changes groups:

- adding/removing/changing sorting return type. Consumer may rely on the way array is sorted or not sorted in the return of API.

- evaluation side effect. Chat GPT stores and "remembers" history by a chat id. Breaking change may appear if the storing algorithm is changed or how the history is red.

- additional constraints/validation on input

- adding/changing/removing implicit modification logic. As an example: submit the form and some default values are applied. Changes in the implicit date formatting, changes in the timezone, setting date to an attribute changes.

Let's explore a **`lodash`** again. In a [changelog](https://github.com/lodash/lodash/wiki/Changelog) we can find breaking changes in a version 3.0.0. When semver major version changes, it indicates, that API contains semantic breaking changes.

```javascript
var array = [1],
    wrapped = _(array);

// in 2.4.1
var a = wrapped.push(2), // pushes `2` to `array`
    b = wrapped.push(3); // pushes `3` to `array`

a.value(); // ➜ returns `array`; [1, 2, 3]
b.value(); // ➜ returns `array`; [1, 2, 3]

// in 3.0.0
var a = wrapped.push(2), // creates a lazy sequence to push `2` to `array`
    b = wrapped.push(3); // creates a lazy sequence to push `3` to `array`

a.value(); // ➜ pushes `2` to `array` and returns `array`; [1, 2]
b.value(); // ➜ pushes `3` to `array` and returns `array`; [1, 2, 3]
a.value(); // ➜ pushes `2` to `array` and returns `array`; [1, 2, 3, 2]
b.value(); // ➜ pushes `3` to `array` and returns `array`; [1, 2, 3, 2, 3]

// use `_#commit` to commit a sequence and continue chaining
var a = wrapped.push(2).commit(), // pushes `2` to `array`
    b = wrapped.push(3).commit(); // pushes `3` to `array`

a.value(); // ➜ returns `array`; [1, 2, 3]
b.value(); // ➜ returns `array`; [1, 2, 3]
```

This example depicts none of the structural changes. But calling the same function in different major versions (2.x and 3.x) results in different inner state of closure.

## **How to avoid breaking changes?**

Structural breaking changes can be avoided by providing additional method/function/constructor/class. Consider the case with the **`lodash`** and **`forEach`**. **`lodash`** could avoid the breaking changes by adding another method/function instead of **`forEach`**, they could add **`forEachLazy`** or **`lazyForEach`** which will provide the same eager API as in 2.x version. Another option how to avoid breaking changes is create new lazy API, by adding an additional parameter to the default export function as **`_.({lazy: true})`**. In this case only lazy wrapper with explicitly called **`value()`** method will be created.

## **Why we are doing breaking changes?**

An example with **`forEach`** has two options how to avoid breaking changes.

- add another method/function **`forEachLazy`**

- add function overload for a default **`lodash`** function with additional optional parameters.

Both of these cases will complicate **`lodash`** API, will make it less consistent with other functions. Also it will increase maintenance cost of two different approaches to be handled for array methods.

These two reasons are not the only reasons to make breaking changes. In my opinion those are the main reasons. To make decision you need to balance between API complexity / maintenance cost and consumer migration cost / benefit.

Breaking Changes

The challenge of rendering HTML markup has been present since the inception of the web. This problem is solved by a multiple patterns mostly on the server side. Such patterns as Template View, Two Step View and Transform View are described in the Martin Fowler's book (2002) Patterns of Enterprise Application Architecture. Depending on the complexity of UI and the domain model Martin suggests different patterns. All these patterns work with [MVC] (https://www.buzzchart.info/post/model-view-controller) very well.

What I found peculiar, in the pattern Transform View, that it has very similar principals to all modern component base web frameworks.

This is the quote from a book:

> Using Transform View means thinking of this as a transformation where you have the model's data as input and its HTML as output.

In comparison to React, the Transform View concept can be reimagined as using React to transform model data into JSX output.

The React has broader and more abstract definition. It's main concept to have a UI as a composition of small components, that can be reused. This paradigm empowered by JSX creates flexible and system of defining and reusing components.

Transform View pattern is focused on the Domain model rendering. In this case class method, that corresponds to the Domain model entity or attribute knows how to create HTML. Back in the 2002, when the book was written, to solve this problem another "language" was used called XSLT, which stands for Extensible Stylesheet Language Transformations. XSLT is a language, XML based, which allows you to define transformations. XSLT supports elements like if, else, for, choose template, choose stylesheet.

In Transform View pattern you will combine your transformations defined XSLT and render those to the HTML.

I am comparing here XSLT and JSX. XSLT can include another XSLT, which provides nesting capabilities. But defining components together with the JavaScript code in the JSX and reusing components in the JSX, was the reason React has such a widespread adoption. I think that Developer Experience DX, dictates what technology is used in the long run. Despite being an appropriate choice at the time, XSLT was eventually sidelined because of its cumbersome XML syntax and lack of development tooling.

Transform View

Model View Controller is a well known pattern, which was described in the late 1970s. Since then, it is widespread architectural pattern, which influenced many frameworks and applications. For example in Java's well known framework [Spring](https://spring.io/guides/gs/serving-web-content) has element which is called **`@Controller`**, which represents a group of endpoints to handle input. Laravel is a PHP framework which is based on the MVC architecture.

MVC implies separation of concerns, where each element is responsible for a specific role.

**Model** - Model is responsible for managing data, business logic, business rules. Commonly used pattern, Domain Model, perfectly fits into MVC. Model is represented in the user interface(UI). UI in MVC is View.

**View** - View is responsible only for a rendering of a model. It can be a single template or by UI framework (library) rendered HTML. In MVC UI layer must not contain business logic, routing, orchestration, database querying. Only rendering the model representation. All these concerns are handled by a Controller element.

**Controller** - Controller accepts input, queries domain model object from a Model, calls services(notifications, logging, mutates data, queries other data sources). Prepares model for the UI, gets the View element. Combines View with the Model and returns HTML to the user.

Separation of an application code to different elements, has multiple benefits:

- each element can be tested in isolation, without a big effort. You can test your Model and View as a pure function. Model can be a complex component, with thousands of business rules and interrelated domain entities logic. Defining and testing those can become challenging. If you will add another layer of complexity, testing it in the presentation layer, you will lose the ability to test or to maintain tests.

- The concerns are fundamentally different. In enterprise applications, separate roles of employees are developing separate layers. For example business analysts will define the domain and business rules. UI developer will develop UI components/views to render a model. Backend developer will manage input to the controller.

- Having separate View from Model layers provides a possibility to implement different representations for different user groups. For example front office with customers, and back office with the employees working on a product, will have different representation of the Model and different application capabilities.

Since the 1970 pendulum swings from the server rendered application to the client rendered application (SPA, single page application), back and forth. MVC is not always applicable, though it even not always can be applied. This architectural pattern must be used to maintain application complexity. If the application is very small and there is no plans to grow this application, the MVC is a complexity itself, that needs to be managed. The majority of the internet is simple representational pages, created with Wordpress on PHP with a help of UI style utils/components like bootstrap and wordpress PHP plugins. On the other side enterprise application with a terabytes of data and millions of users with myriads of roles/privileges/use cases which you (as a developer/architect) need to handle.

MVC is about the separation of concerns, this means that you need to work hard to enforce it. Enforcing the separation can become challenging. On one hand you have requirements for complex interface, where developer wants to include the domain logic in the representation. On another hand you have a requirement to isolate business/domain logic from the representation. Which is possible, but it can become difficult, if incorrect abstraction is used. This separation can fail if:

- there is not architectural governance in the development process.

- developer will chose the environment, which is know for him. If he needs to switch tools/programming languages/repositories, most likely he will avoid it and mix the concerns.

- tools provided for developers are flexible enough to mix concerns. React with JSX, as an example, is the most powerful templating language for HTML (comparing to mustache, pug or others).

- time constraints are dictating the technical decision.

- current architecture does not support (or the complexity is too high to implement in other environment/tool/place) the required feature to be implemented in the Controller or Model.

Model View Controller MVC

ACID (Atomicity, Consistency, Isolation, Durability) in IT is a properties of a business (or database) transactions, that guarantees the reliability and data integrity of the transaction.

- **Atomicity** - transaction as one unit. If one operation of transaction fails, the transaction is failed

- **Isolation** - concurrent transactions are shielded form the "effects" of other transactions

- **Consistency** - from one consistent database state to another to another consistent database state

- **Durability** - guarantees that once a transaction is committed, changes will survive any system failures

ACID in Database Transactions

Concurrency is a complex problem of the IT field. I'll try to explain some issues related to the concurrency and how to solve those issues.

**Concurrency Issues:**

- 🍎🍊 inconsistent reads - when the data is modified by a different actors. Depending on when you transaction starts reading the data and how log this transaction spans, you can get (read) different values.

- 💥🍎 lost updates - when 2 transactions are spanned different time and modifying the same entity. Last ended transaction will override first transaction result.

**Solutions: Optimistic Lock:**

🔓Optimistic Lock - concurrency control mechanism, which allows to write data simultaneously from the different transactions. It is called optimistic, because the assumption is that the collisions (conflict) will not be frequent.

- ✔️ better performance duo to improved concurrency in the system

- ❌ need to handle the collisions (conflicts)

**Solutions: Pessimistic Lock:**

🔒Pessimistic Lock - concurrency control mechanism, which locks the resources, processed by a transaction.

- ✔️ improves application durability and data constancy

- ❌ degrades the application performance and availability

- ❌ can create a Dead Lock

**Avoiding Deadlocks:**

☠️🔒 Is a situation, when locks are applied on resources, which are required in other transactions. If you have 2 transactions:

- acquires lock on a "Book" entity and later want to acquire lock on "Author" entity

- acquires lock on a "Author" entity and later want to acquire lock on "Book" entity In order to finish one transaction you need to acquire lock, on a resource, which is locked by other transaction. When none of transactions cannot be completed, this situation is called a Dead Lock.

_Patterns of Enterprise Application Architecture: Martin Fowler, with Dave Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford_

_Note: The content in this article is a summary/interpretation inspired by them. Proper attribution is given to the respective authors._

Concurrency Issues and Solutions

In the book Patterns of _Enterprise Application Architecture by Martin Fowler_ two patterns are defined to handle business logic in the system. I do not think that much have changed since then. The IT industry evolved, but these patterns are still applicable to this day. I will unpack what those patterns mean and how they are applicable now.

**Domain model** is a pattern where object representing the model also contains the behavior and/or business rules in itself.

- ✔️ data together with the behavior

- ✔️ easy to extend

- ✔️ easy to comprehend / observe if applied correctly

- ❌ requires more effort and experience to implement

- ❌ may be overhead for a simple domain

**Transaction script** is a pattern where a separate script/object/function/service loads the data validates/modifies it and saves to the database.

- ✔️ requires less effort and experience to implement

- ✔️ fits simple domain applications

- ❌ anemic model, which is considered as an anti-pattern by a Martin Fowler

- ❌ hard to maintain / extend / observe on a more complex domain

Both of these patterns are pretty abstract and can be applied today with other architectural and design patterns. Each of those has pros and cons. You can use these pattern in your server side rendered UI MVC application with, react server components, PHP or Java server pages.

## **Difference**

The difference between those patterns is complexity. Complexity of implementation, extensions and support. Domain model can harder to implement initially. But it reduces the complexity, when the model is evolving, getting more complex. Keeping business logic in one place with the domain reduces the complexity of extension and refactoring. On the other hand transaction script separates data from the behavior. At the start it is easier to model you data and write a transaction script to handle business rules. But this approach will not scale, with the size of your model and the domain complexity.

## **Challenges**

At the time _Martin Fowler wrote the book Patterns of Enterprise Application Architecture_ was written, the standard UI architecture was HTML rendered on server with a small amount of interactivity sprinkled by javascript. All logic could be handled by both patterns on the server. Mostly it is MVC pattern for a web server with a input controller acting as a mediator. Today the expectations of the UI/UX have changed. UI is way more interactive - UI applications handles routing, validation, data initialization and manipulation, UI flow management, security and whats not. Previously UI was not responsible for all those things. This is why implementing business logic in the maintainable manner is crucial for a modern UI application. Domain model is one of the options, which must be considered. If you will leave the majority of these concerns on the server, then UI will request those. Multiple requests will degrade the responsiveness of an application.

## **Examples**

For example consider case when you need to validate the 1mb json data. You have thousands of business rules, which must be evaluated, to ensure the data is valid. During the data gathering process you will make thousands REST API calls to the server to validate the data, to provide instant feedback on entered values. If you will choose to make validation once per tab/dropdown/card/step, then user will have a bunch of errors after he completed the step. This can be a tradeoff of keeping the logic on the backend and requesting this logic from the server.

- using transaction script you will end up with thousands of functions, with duplicated logic between those and the code which is hard to comprehend.

- using the domain model pattern your business rules will be "managed" together with the model. Rules will be kept with the domain which matches the Single responsibility principle.

Domain Model vs Transaction Scripts

Microservices can communicate synchronously and asynchronously. These are the main group of communication means for microservices. Lest dig in to unwrap, what does it mean.

**Synchronous communication** means is sending a request to another microservice and waiting for a response. Opening a connection and waiting for a response. This is the most simple communication option for microservices. It is easy to implement and use, but it has its tradeoffs. The tradeoff is that your microservice is blocked by another microservice response. This type of communication creates [temporal coupling](https://www.buzzchart.info/post/coupling-and-cohesion). The implementation of synchronous communication can be either HTTP REST call calls or RPC.

_When to use?_

- Used when the user or client of the microservice expects an 'immediate' response. For example calculate book price based on all gathered parameters.

- You are implementing [distributed transaction](https://www.buzzchart.info/post/distributed-transactions-in-microservices) and want your application state to be as [consistent](https://www.buzzchart.info/post/cap-theorem) as possible.

_Pros and cons_

✔️ simple to implement.

✔️ simple to understand (observe) the system.

❌ creates [temporal coupling](https://www.buzzchart.info/post/coupling-and-cohesion) in the application.

❌ can cause performance issues in case target microservice is slow or overloaded.

❌ opens a lot of connections for big traffic. In case microservice throughput is limited, then it can cause a major performance issues.

**Asynchronous communication** is a communication style, when you are not getting the response right away. In some cases you are not getting a response at all. Three groups of communication patterns can be utilized for asynchronous programming.

- Request-Response communication - can be implemented as sync and also async with the queue based message brokers. Two queues are present, for requests and for responses. The sender will get the response from the queue marked with the correlation id.

- Event-driven communication - is communication pattern where sender does not wait for the response at all. It emits the event via the message broker. Other microservices can consume the event, if they are subscribed to it. This pattern ✔️ decouples microservices and letting them communicate via strictly defined interfaces. This pattern implies the ❌ complexity in understanding the application as a whole. The [observability tools and practices](https://www.buzzchart.info/post/observability) can help this problem.

- Common data communication - is a pattern when all microservices are writing to the same data store. It can be filesystem or database. Then other microservices can read from this data storage. This pattern creates a ❌ [common coupling](https://www.buzzchart.info/post/coupling-and-cohesion) (writing to the same data store) between microservices, but it is ✔️ simple to implement and maintain.

_Pros and Cons_

✔️ decouples microservices, letting them evolve independently

❌ increases complexity in the application

_When to use?_

- Use it when you need to decouple microservices. This communication style allows to do it completely.

- Use it for a long lived tasks. These tasks cannot provide immediate response. For example you need to check the number of books in the warehouse, before sending and marking in the system that it is sent. This type of task cannot be done synchronously.

_Microservices, 2nd edition by Sam Newman_

_Fundamentals of Software Architecture: An Engineering Approach 1st Edition by Mark Richards (Author), Neal Ford_

Note: The content in this article is a summary/interpretation inspired by them. Proper attribution is given to the respective authors.

Microservice Communication Patterns

Domain driven design (DDD) is a methodology for designing software with a focus on the domain. DDD is one of the main practices used in the microservices development. I'll cover 3 main concepts of the DDD:

- Ubiquitous Language - use the same language/terms in the code and in the business. This allows programmers to talk to the business people without misinterpretation.

- Aggregate - Related objects, that form a consistency boundary and are treated as a single unit. For example in the "Customer" domain, "Address" is an aggregate.

> An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each aggregate has a root and a boundary. The boundary defines what is inside the aggregate. The root is a single, specific ENTITY contained in the aggregate.

_Domain Driven Design, Eric Evans_

- Bounded Context - a logical and physical boundary around a coherent and consistent domain or subdomain

What if you already have a domain and want to slice it to migrate from the monolith to the microservices, for example? You can do this using these patterns:

- Volatility - split by the performance sensitive parts

- Data - split by usage or restrictions on the data

- Technology - split by a technology stack

- Organizational - align with the company organizational structure

_Microservices, 2nd edition by Sam Newman_

Domain Driven Design

CAP abbreviation means: Consistency, Availability and Partitioning tolerance. Theorem states, that distributed data store can have two of three guarantees:

- Consistency - every read from the store will receive most recent write result.

- Availability - application is highly available. Almost all requests will be returned with a response.

- Partitioning tolerance - ability to distribute / partition data store.

In microservice architecture, which is distributed by its nature, you cannot have option CA.

- You can choose from the PA and data will be eventually consistent.

- Or you can have CP, but not always an available service to respond. Handling distributed data stores syncing can take time. This means you need to use locks and persistent queues to support data sync.



CAP theorem

Transactions in microservices are not possible, because of the distributed nature of microservices. Though you can implement compensation mechanisms to handle failures in multiple microservices calls for one business action. There are patterns to handle this situation:

- 2 Phase commit - pattern to check, wether microservice is able to write with this data before actually making the 'writing'.

- Choreography-based saga - Multiple 'write' calls, where microservices are called in the chain. Each subsequent call of microservice knows how to rollback or compensate the 'write' call. This type of saga is easier to implement. It is More decoupled, than orchestration based saga. However, it is harder to grasp the whole business process.

- Orchestration-based saga - This pattern implies, that you have an "orchestrator" microservice. It will calls different microservices and knows how to compensate fail 'write' call. The business process is easier to understand from the saga implementation. However, it introduces domain coupling on different microservice domains.

! what is worth mentioning: Do not implement sagas. Saga introduces complexity to your microservices (both book authors have the same opinion).

! ACID is not supported in the microservices

_Microservices, 2nd edition by Sam Newman_

_Fundamentals of Software Architecture: An Engineering Approach 1st Edition by Mark Richards (Author), Neal Ford_

Distributed "Transactions" in Microservices

Coupling types listed from the weakest:

- Domain coupling - different modules shares the same domain

- Temporal coupling - coupling in time, when one module assumes, that antoher will be available at time the communication

- Pass-through coupling - module takes data structure and passes to another module

- Common coupling - modules write to the same database

- Content coupling - modules modifies the same database table

_Microservices, 2nd edition by Sam Newman_

_Fundamentals of Software Architecture: An Engineering Approach 1st Edition by Mark Richards (Author), Neal Ford_

Coupling & Cohesion

- Page based decomposition - each microservice has ts own dedicated page. This pattern enables vertical slice of an application. ✔️ You can deploy your UI and backend for a vertical slice of an application independently from other microservices. ❌ Has limited capabilities creating complex UI.

- Widget based decomposition - each widget can communicate only with it's own microservice. ✔️ You can deploy your UI and backend for a vertical slice of an application independently from other microservices. ❌ Adds complexity in managing communication between widgets.

- Central Aggregating gateway - gateway (with transformation, filtering, aggregation) as a single entrypoint to the microservices. Good fit when you have a separate UI teams and microservices teams. Creates horizontal layers of an application (n-tier architecture). ✔️ Simplifies UI development. ❌ Creates coupling on the gateway side.

- Backend For Frontend (aka BFF) - same as CAG per client type. This pattern fits, when you have multiple client types (web, ios, android, 3rd party API). ✔️ It solves the general purpose API problem and enables teams to develop independently. ❌ It creates coupling on the gateway layer, and introduces code duplication.

_patterns by Sam Newman from the book Microservices 2nd edition_