Mastering Microservice Design Patterns: Decomposition & Integration Strategies

This article aims to help readers understand microservice architecture design patterns to overcome the challenges of microservices. It is divided into two parts: the first part covers the Decomposition Pattern and Integration Pattern; the second part will discuss Database Pattern, Observability Pattern, and Cross‑cutting Concern Pattern.

Scalability

Availability

Resilience

Autonomy

Decentralized governance

Fault isolation

Automated provisioning

Continuous delivery via DevOps

1. Decomposition Pattern

a. Business‑Capability Decomposition

Problem : Microservices aim for loose coupling and single‑responsibility, but breaking an application into smaller services must be done logically. How can an application be decomposed into small services?

Solution : Decompose based on business capabilities. Each capability (e.g., sales, underwriting, claims processing) can be treated as a service focused on business value rather than technical concerns.

b. Subdomain Decomposition

Problem : Using business‑function decomposition may lead to “God classes” that are hard to split across services, such as an Order class used for order management, revenue, delivery, etc.

Solution : Apply Domain‑Driven Design (DDD). Identify subdomains and bounded contexts; each microservice is built around a bounded context, avoiding God classes.

c. Killer Pattern

Problem : The discussed patterns focus on greenfield applications, but most work involves refactoring large monoliths (brownfield). Applying these patterns to a monolith is difficult.

Solution : Use the “Killer” pattern, analogous to a vine wrapping a tree. Incrementally create independent services for each domain while keeping them in the same URI space, gradually replacing the monolith.

2. Integration Pattern

a. API‑Gateway Pattern

Problem : How to invoke multiple microservices to retrieve producer information. Different channels (desktop, mobile, tablet) need different data from the same backend services. Different consumers may require different response formats; who performs data transformation? How to handle various protocols, some of which may not be supported by producer services.

Solution : The API gateway serves as a single entry point for all microservice calls. It acts as a proxy, routing requests to appropriate services and abstracting producer details. It can fan‑out requests to multiple services, aggregate results, and return a unified response. Fine‑grained APIs can be created for specific client types. It can translate protocols (e.g., AMQP to HTTP) to enable interoperability. It offloads authentication/authorization responsibilities from individual services.

b. Aggregator Pattern

Problem : When decomposing business functions into smaller services, coordinating data returned by each service becomes a challenge; the consumer should not need to know internal producer implementations.

Solution : The Aggregator pattern solves this by either: Using a composite microservice that calls required services, merges and transforms data before responding. Having the API gateway split the request, invoke multiple services, and aggregate the data before returning it. If business logic is needed, prefer a composite microservice; otherwise, the API gateway suffices.

c. Client‑Side UI Composition Pattern

Problem : When services are built by decomposing business capabilities, the UI service must gather data from multiple microservices. In monolithic apps a single call retrieves all data; now multiple calls are needed.

Solution : Design the UI as a skeleton of multiple screen/region components, each calling a single backend microservice for its data. Frameworks like AngularJS or ReactJS enable this Single‑Page Application (SPA) approach, allowing partial screen refreshes instead of full page reloads.

Summary

In this part we introduced the Decomposition and Integration patterns. The next article will cover Database, Observability, and Cross‑cutting Concern patterns to further aid understanding of microservices.