Microservices Patterns: Principles and Design Solutions

Microservices architecture is built on the following principles:

• Scalability
• Availability
• Resiliency
• Independence and Autonomy
• Decentralization
• Failure Isolation
• Auto-Provisioning

While these principles provide many benefits, they also introduce challenges. To address these challenges, specific design patterns are employed:

Decomposition Patterns

1. Decompose by Business Capability: This approach involves breaking down services based on business capabilities, such as sales, marketing, and accounting, making services loosely coupled and independent.
2. Strangler Pattern: This pattern allows for the incremental transformation of a monolithic application into microservices by gradually replacing specific functionalities with new services. Once the new service is operational, the old component is phased out.

Integration Patterns

1. API Gateway Pattern: An API Gateway serves as a single entry point for all microservice calls, handling tasks such as authentication, authorization, rate limiting, retry policies, and circuit breaker implementations.
2. Client-Side UI Composition Pattern: When the UI requires data from different services, it is designed with multiple sections, each making calls to individual microservices. This enables the app to refresh specific regions of the screen instead of the entire page.
3. Database Per Service: Each microservice has its own database, ensuring independence. This pattern can use private tables per service in relational databases, without requiring separate database servers.

Query Handling Patterns

1. API Composition Pattern: This pattern involves clients (often using a Feign Client) calling services that own the data and combining the results. It's simple and effective for direct queries but can be cumbersome for complex queries requiring in-memory joins.
2. Aggregator Pattern: In this pattern, an aggregator service receives a user request, calls multiple microservices, collects data, and returns the result to the user. Microservices are usually called in parallel, although sequential calls may be necessary if dependencies exist. Note that this can increase network calls and reduce overall service availability.
3. Command Query Responsibility Segregation (CQRS): CQRS separates write operations (commands) and read operations (queries), typically using two databases. The query database is kept up-to-date with events from the command side, often through materialized views. This pattern is powerful but complex, providing efficient query handling by subscribing to event streams from multiple databases.
4. SAGA Pattern: The SAGA pattern is a crucial design solution for managing distributed transactions in a microservices architecture. It ensures data consistency across multiple services by breaking down a transaction into a series of smaller, manageable steps, each with its own compensation logic. The SAGA pattern is discussed in detail in a separate topic.

https://www.dhirubhai.net/pulse/saga-pattern-distributed-transaction-management-said-naeem-shah-wsemf/?trackingId=V7Bx26H%2BRkSEIpgrNTV1Uw%3D%3D