Card Image

| 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:

  1. Microservice Architecture
  2. Advantages of Microservice Architecture
  3. Disadvantages of Microservice Architecture
  4. When to use Microservice Architecture
  5. 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.



Let’s Get in Touch

LET'S TALK ABOUT YOUR BUSINESS IT SERVICES NEEDS