Microservice Architecture and Design Patterns: Goals, Principles, and Decomposition Strategies

Microservices can bring positive impacts to enterprises, so understanding Microservice Architecture (MSA) and its design patterns is valuable. Four common goals of an MSA are cost reduction, faster release speed, increased resilience, and better visibility.

The architecture should follow several design principles such as scalability, availability, resilience, flexibility, autonomy, decentralized governance, fault isolation, auto‑configuration, and DevOps‑driven continuous delivery.

To apply these principles, various decomposition patterns are introduced:

Decompose by business function (e.g., order‑management service, customer‑management service).

Decompose by domain sub‑domains (core, supporting, generic) using Domain‑Driven Design.

Decompose by transaction/2‑phase commit (2PC) – noting its performance drawbacks.

Strangler Pattern – transform, coexist, eliminate legacy monoliths.

Bulkhead Pattern – isolate components to prevent cascading failures.

Sidecar Pattern – run auxiliary functionality in a separate container alongside the main service.

Integration patterns include:

API‑Gateway – a single entry point that routes, aggregates, transforms protocols, and handles authentication/authorization.

Aggregator – combines data from multiple services either via a composite service or the gateway.

Proxy – exposes microservices through distinct API modules (mobile, browser, public).

Routing – maps HTTP methods and paths to service URLs, similar to reverse‑proxy behavior.

Chained Microservice – services call each other synchronously in a chain.

Branch Pattern – parallel calls to multiple services with combined responses.

Client‑UI Composition – UI components (e.g., Angular, React) each fetch data from dedicated backend services.

Database patterns discuss the “database‑per‑service” approach, the drawbacks of shared databases, and the need for private tables, schemas, or dedicated database servers per service.

Command‑Query Responsibility Segregation (CQRS) separates write (command) and read (query) sides, often paired with event‑sourcing to keep materialized views up‑to‑date.

Saga patterns ensure data consistency across services via choreography (event‑driven) or orchestration (central coordinator).

Observability patterns cover log aggregation, performance metrics (push vs pull), distributed tracing with request IDs, and health‑check endpoints.

Cross‑cutting concerns include external configuration, service discovery (client‑side like Netflix Eureka or server‑side like AWS ALB), circuit‑breaker to prevent cascading failures, and blue‑green deployment to achieve zero‑downtime releases.