
| Ganesha Siagian
10 Most Important Microservice Architecture Design Patterns
Tackling complexity in large Software Systems was always a daunting task since the early days of Software development (1960's). Over the years, Software Engineers and Architects made many attempts to tackle the complexities of Software Systems: Modularity and Information Hiding by David Parnas (1972), Separation of Concern by Edsger W. Dijkstra (1974), Service Oriented Architecture (1998).
All of them used the age-old and proven technique to tackle the complexity of a large system: divide and conquer. Since the 2010s, those techniques proved insufficient to tackle the complexities of Web-Scale applications or modern large-scale Enterprise applications. As a result, Architects and Engineers developed a new approach to tackle the complexity of Software Systems in modern times: Microservice Architecture. It also uses the same old “Divide and Conquer” technique, albeit in a novel way.
Software Design Patterns are general, reusable solutions to the commonly occurring problem in Software Design. Design Patterns help us share a common vocabulary and use a battle-tested solution instead of reinventing the wheel. In a previous article: Effective Microservices: 10 Best Practices, I have described a set of best practices to develop Effective Microservices. Here, I will describe a set of Design Patterns to help you implement those best practices. If you are new to Microservice Architecture, then no worries, I will introduce you to Microservice Architecture.
Today we will focus in:
- Microservice Architecture
- Advantages of Microservice Architecture
- Disadvantages of Microservice Architecture
- When to use Microservice Architecture
- The Most important Microservice Architecture Design Patterns, including their advantages, disadvantages, use cases, Context, Tech Stack example, and useful resources.
Microservice Architecture is about splitting a large, complex systems vertically (per functional or business requirements) into smaller sub-systems which are processes (hence independently deployable) and these sub-systems communicates with each other via lightweight, language-agnostic network calls either synchronous (e.g. REST, gRPC) or asynchronous (via Messaging) way.
1. Important Characteristics of Microservice Architecture:
- The whole application is split into separate processes where each process can contain multiple internal modules.
- Contrary to Modular Monoliths or SOA, a Microservice application is split vertically (according to business capability or domains)
- The Microservice boundary is external. As a result, Microservices communicates with each other via network calls (RPC or message).
- As Microservices are independent processes, they can be deployed independently.
- They communicate in a lightweight way and don’t need any smart Communication channel.
2. Advantages of Microservice Architecture:
- Better development scaling.
- Higher development velocity.
- Supports iterative or incremental modernization.
- Take advantage of the modern Software Development Ecosystem (Cloud, Containers, DevOps, Serverless).
- Supports horizontal scaling and granular scaling.
- It puts low cognitive complexity on the developer’s head thanks to its smaller size.
3. Disadvantages of Microservice Architecture:
- A higher number of Moving parts (Services, Databases, Processes, Containers, Frameworks).
- Complexity moves from Code to the Infrastructure.
- The proliferation of RPC calls and network traffic.
- Managing the security of the complete system is challenging.
- Designing the entire system is harder.
- Introduce complexities of Distributed Systems.
4. When to use Microservice Architecture:
- Web-Scale Application development.
- Enterprise Application development when multiple teams work on the application.
- Long-term gain is preferred over short-term gain.
- The team has Software Architects or Senior Engineers capable of designing Microservice Architecture.
Design Patterns for Microservice Architecture
Database per Microservice
Once a company replaces the large monolithic system with many smaller microservices, the most important decision it faces is regarding the Database. In a monolithic architecture, a large, central database is used. Many architects favor keeping the database as it is, even when they move to microservice architecture. While it gives some short-term benefit, it is an anti-pattern, especially in a large-scale system, as the microservices will be tightly coupled in the database layer. The whole object of moving to microservice will fail (e.g., team empowerment, independent development).
A better approach is to provide every Microservice its own Data store, so that there is no strong-coupling between services in the database layer. Here I am using the term database to show a logical separation of data, i.e., the Microservices can share the same physical database, but they should use separate Schema/collection/table. It will also ensure that the Microservices are correctly segregated according to the Domain-Driven-Design.