Overview of microservice integration patterns

In this section, we'll discuss design patterns, design principles, and how microservice architectural patterns relate to traditional microservice patterns and can be applied to serverless microservices. These topics will help you gain an overview of different integration patterns.

Design patterns

Patterns are reusable blueprints that are a solution to a similar problem others have faced, and that have widely been reviewed, tested, and deployed in various production environments.

Following them means that you will benefit from best practices and the wisdom of the technical crowd. You will also speak the same language as other developers or architects, which allows you to exchange your ideas much faster, integrate with other systems more easily, and run staff handovers more effectively.

Software design patterns and principles

Your will probably be using object-oriented (OO) or functional programming in your microservices or Lambda code, so let's briefly talk about the patterns linked to them.

In OO programming, there are many best practice patterns or principles you can use when coding, such as GRASP or SOLID. I will not go into too much depth as it would take a whole book, but I would like to highlight some principles that are important for microservices:

SOLID: This has five principles. One example is the Single Responsibility Principle (SRP), where you define classes that each have a single responsibility and hence a single reason for change, reducing the size of the services and increasing their stability.

Package cohesion: For example, common closure-principle classes that change together belong together. So when a business rule changes, developers only need to change code in a small number of packages.
Package coupling: For example, the acyclic dependencies principle, which states that dependency graphs of packages or components should have no cycles.

Let's briefly go into some of the useful design patterns for microservice:

Creational patterns: For example, the factory method creates an instance of several derived classes.
Structural patterns: For example, the decorator adds additional responsibilities to an object dynamically.
Behavioral patterns: For example, the command pattern encapsulates a request as an object, making it easier to extract parameters, queuing, and logging of requests. Basically, you decouple the parameter that creates the command from the one that executes it.
Concurrency patterns: For example, the reactor object provides an asynchronous interface to resources that must be handled synchronously.

Depending on you coding experience, you may be familiar with these. If not, it's worth reading about them to improve you code readability, management, and stability, as well as your productivity. Here are some references where you can find out more:

SOLID Object-Oriented Design, Sandi Metz (2009)
Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1995)
Head First Design Patterns, Eric T Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra (2004)
Agile Software Development, Principles, Patterns, and Practices, Robert C. Martin (2002)

Serverless microservices pattern categories

On top of the software design patterns and principles we just discussed are the microservices patterns. From my experience, there are many microservices patterns that I recommended that are relevant for serverless microservices, as shown in the following diagram:

I created this diagram to summarize and illustrate the serverless microservices patterns we will be discussing in this book:

Communication styles: How services communicate together and externally.
Decomposition pattern: Creating a service that is loosely coupled by business capability or bounded context.
Data management: Deals with local and shared data stores.
Queries and messaging: Looks at events and messages that are sent between microservices, and how services are queried efficiently.
Deployment: Where ideally we would like uniform and independent deployments, you also don't want developers to re-create a new pipeline for each bounded context or microservice.
Observability and discovery: Being able to understand whether a service is functioning correctly, monitor and log activity allow you to drill down if there are issues. You also want to know and monitor what is currently running for cost and maintenance reasons, for example.
Security: This is critical for compliance, data integrity, data availability, and potential financial damage. It's important to have different encryption, authentication, and authorization processes in place.