Tuesday, December 31, 2019

Microservice Architecture Design patterns


What are Microservices?
Microservices is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain. In a Microservice Architecture, each service is self-contained and implements a single business capability.
Principles Used to Design Microservice Architecture
The principles used to design Microservices are as follows:
1.    Independent & Autonomous Services
2.    Scalability
3.    Decentralization
4.    Resilient Services
5.    Real-Time Load Balancing
6.    Availability
7.    Continuous delivery through DevOps Integration
8.    Seamless API Integration and Continuous Monitoring
9.    Isolation from Failures
10. Auto -Provisioning







Application architecture patterns
  • Monolithic architecture -  architect an application as a single deployable unit
  • Microservice architecture - architect an application as a collection of independently deployable, loosely coupled services

Decomposition
  • Decompose by business capability - define services based on business capabilities
  • Decompose by subdomain - define services based on DDD subdomains
  • Self-contained Service - design services to handle synchronous requests without waiting for other services to respond
  • Service per team

Refactoring to microservices

Data management
  • Database per Service - each service has its own private database, Prevents tight coupling.
  • Shared database - services share a database, Temporary solution during migration.
  • Saga - use sagas, which a sequences of local transactions, to maintain data consistency across services
  • API Composition - implement queries by invoking the services that own the data and performing an in-memory join
  • CQRS - implement queries by maintaining one or more materialized views that can be efficiently queried
  • Domain event - publish an event whenever data changes
  • Event sourcing - persist aggregates as a sequence of events
Transactional messaging
  • Transactional outbox
  • Transaction log tailing
  • Polling publisher
Testing
  • Service Component Test - a test suite that tests a service in isolation using test doubles for any services that it invokes
  • Consumer-driven contract test - a test suite for a service that is written by the developers of another service that consumes it
  • Consumer-side contract test - a test suite for a service client (e.g. another service) that verifies that it can communicate with the service
Deployment patterns
  • Multiple service instances per host - deploy multiple service instances on a single host
  • Service instance per host - deploy each service instance in its own host
  • Service instance per VM - deploy each service instance in its VM
  • Service instance per Container - deploy each service instance in its container
  • Serverless deployment - deploy a service using serverless deployment platform
  • Service deployment platform - deploy services using a highly automated deployment platform that provides a service abstraction
Cross cutting concerns
  • Microservice chassis - a framework that handles cross-cutting concerns and simplifies the development of services
  • Externalized configuration - externalize all configuration such as database location and credentials
Communication style
  • Remote Procedure Invocation - use an RPI-based protocol for inter-service communication
  • Messaging - use asynchronous messaging for inter-service communication
  • Domain-specific protocol  - use a domain-specific protocol
External API
  • API gateway  - A single entry point that routes requests to microservices.
  • Backend for front-end - a separate API gateway for each kind of client, ex: Different gateways for Web App, Mobile App, Admin App. Avoids frontend complexity. ex: A mobile user gets compressed JSON tailored for mobile.
Service discovery
  • Client-side discovery - client queries a service registry to discover the locations of service instances
  • Server-side discovery- router queries a service registry to discover the locations of service instances
  • Service registry - a database of service instance locations
  • Self registration - service instance registers itself with the service registry
  • 3rd party registration- a 3rd party registers a service instance with the service registry
Reliability
  • Circuit Breaker  - Stops calling failing services temporarily, so Prevents cascading failures. Tools: Resilience4j, Netflix Hystrix (legacy)
Security
  • Access Token - a token that securely stores information about user that is exchanged between services
Observability
  • Log aggregation - aggregate application logs, ELK (Elasticsearch + Logstash + Kibana)
  • Application metrics - instrument a service’s code to gather statistics about operations, Prometheus, Grafana, Micrometer (Java)
  • Audit logging  - record user activity in a database
  • Distributed tracing  - Track API calls across services. tools: Zipkin, OpenTelemetry
  • Exception tracking - report all exceptions to a centralized exception tracking service that aggregates and tracks exceptions and notifies developers.
  • Health check API - service API (e.g. HTTP endpoint) that returns the health of the service and is intended to be pinged, for example, by a monitoring service
UI patterns
  • Server-side page fragment composition - build a webpage on the server by composing HTML fragments generated by multiple, business capability/subdomain-specific web applications
  • Client-side UI composition - Build a UI on the client by composing UI fragments rendered by multiple, business capability/subdomain-specific UI components

API Gateway Pattern

How to explain in interview

“API Gateway is a single-entry point for all client requests. It handles routing, authentication, rate-limiting, and API aggregation before forwarding to backend microservices.”

Problems it solves

  • Removes client-to-multiple-service complexity
  • Centralized auth
  • Prevents exposing internal microservices
  • Supports canary release & throttling

Use case

Mobile app + web app → need lightweight, optimized API responses.

Java tools

  • Spring Cloud Gateway
  • Netflix Zuul
  • Kong / Nginx

Follow-up question

If API Gateway goes down, whole system fails — how do you avoid?
✔ Answer: Run gateway in active-active mode behind a load balancer, with autoscaling & distributed config.

Backend For Frontend (BFF)

Interview explanation

“BFF creates separate gateways for mobile, web, and partner applications so that each frontend gets a tailored response.”

When needed

  • Mobile app needs fewer fields
  • Web UI needs detailed data

Tools

  • Spring Boot BFFs
  • GraphQL BFF (Netflix uses)

Follow-up

❓ Difference between API Gateway and BFF?
✔ Answer: BFF is client-specific; Gateway is system-wide.

Saga Pattern – (MOST IMPORTANT for architect interviews)

Interview explanation

“Saga handles distributed transactions across microservices using either choreography (events) or orchestration (central controller). It replaces 2PC in microservices.”

Why needed

  • DB per service means no cross-service transactions
  • Ensures consistency using compensating actions

Example

Order → Payment → Inventory
If inventory fails → compensate Payment → compensate Order.

Implementations

  • Choreography: Kafka events
  • Orchestration: Camunda / Temporal / Axon

Follow-up

❓ When to use choreography?
✔ Lightweight, fewer services, event-driven.

❓ When to use orchestration?
✔ Complex workflows, error handling, timeouts.

CQRS (Command Query Responsibility Segregation)

Interview explanation

“CQRS separates write (commands) and read (queries) models to improve performance, scalability, and optimizes read-heavy systems.”

Benefits

  • Read DB can be NoSQL & denormalized
  • Commands enforce validations
  • Event sourcing integrates naturally

Use case

  • Banking
  • Wallet applications
  • Order tracking dashboards

Follow-up

❓ Downsides of CQRS?
✔ More complexity, eventual consistency, duplicate databases.

Event Sourcing

Interview explanation

“Instead of saving final state, we store all events. System state can be rebuilt by replaying events.”

Benefits

  • Perfect audit history
  • Rollback to past states
  • High write performance

Use case

  • Ledger systems
  • Audit-driven domains
  • Payment & transactions

Java tools

  • Axon
  • EventStoreDB

Follow-up

❓ How do you prevent event store from becoming too large?
✔ Snapshotting after fixed number of events.

Strangler Fig Pattern (Migration Pattern)

Interview explanation

“We gradually replace a monolith by routing specific functionality to a new microservice until the monolith is fully replaced.”

When needed

  • Legacy → Microservices migration
  • Zero downtime rollout

Example

Move inventory functionality from monolith → microservice → redirect traffic via gateway.

Follow-up

❓ How do you ensure backward compatibility?
✔ Versioned APIs and backward-compatible schema changes.

Database per Service Pattern

Interview explanation

“Each microservice owns its database. This decouples services, enables independent scaling, and avoids distributed locking.”

Challenges solved

  • No shared schema
  • No runtime coupling
  • Independent release cycles

Hard question

❓ How do you maintain data integrity without foreign keys?
✔ Using Saga, events, or domain-driven consistency guarantees.

Outbox Pattern

Architect-level explanation

“Outbox ensures reliable event publication using a single local transaction: write to DB + write event into outbox table.”

Then a background job publishes events to Kafka.

Why needed

  • Prevents lost events during crashes
  • Ensures atomicity without 2PC

Follow-up

❓ How do you implement Outbox efficiently?
✔ With Debezium CDC + Kafka; avoids custom polling.

Circuit Breaker Pattern

Interview explanation

“Circuit breaker stops calling failing services and gives fallback immediately. This avoids cascading failures.”

Java tools

  • Resilience4j (recommended)
  • Hystrix (deprecated but still asked)

State transitions

  • Closed → Open → Half-Open → Closed

Follow-up

❓ Difference between retry & circuit breaker?
✔ Retry handles temporary failures; circuit breaker handles persistent failures.

Bulkhead Pattern

Interview explanation

“Bulkhead isolates resources (thread pools, connections) so failure in one service doesn’t affect others.”

Example

If Payment API is slow → only its pool is consumed → Order API still runs.

1️Retry + Timeout Pattern

Interview explanation

“Retries must be combined with timeouts & backoff to avoid retry storms.”

Java

  • Resilience4j Retry
  • Spring Retry

Follow-up

❓ How many retries?
✔ Based on SLA, usually 2–3 with backoff.

Sidecar + Service Mesh Pattern

Interview explanation

“Service mesh offloads observability, security, and traffic control to sidecars instead of writing logic inside services.”

Features

  • mTLS
  • Retries
  • Circuit breaking
  • Canary & blue-green rollout

Tools

  • Istio / Linkerd

Follow-up

❓ How is service mesh different from API gateway?
✔ Gateway is north-south traffic; mesh is east-west traffic.

Centralized Configuration Pattern

Interview explanation

“Configuration is stored centrally and fetched at runtime.”

Java tools

  • Spring Cloud Config
  • Consul
  • AWS Parameter Store

Benefits

  • Secure secret handling
  • No restart needed
  • Versioned config

Distributed Logging & Tracing Pattern

Interview explanation

“Microservices generate logs in multiple nodes, so we need centralized log aggregation and distributed tracing.”

Tools

  • ELK
  • OpenTelemetry
  • Zipkin
  • Jaeger

Follow-up

❓ How do you trace one request across 20 microservices?
✔ Pass correlation ID through all services (propagated via headers).

Aggregator Pattern

Interview explanation

“Aggregator composes data from multiple microservices into a single response.”

Use case

  • Dashboard API
  • Combining Order + User + Inventory data

Anti-Corruption Layer (ACL)

Interview explanation

“ACL isolates microservices from legacy systems using translation adapters.”

Use case

Legacy SOAP → ACL → New REST Microservice.

Service Registry and Discovery:

    • Pattern: Service Discovery
    • Description: A service registry is used to keep track of the available microservices and their locations. Services register themselves with the registry, and clients can discover and communicate with services through the registry.
    • Benefits: Enables dynamic scaling and seamless service discovery.

 Event Sourcing:

    • Pattern: Event Sourcing
    • Description: Instead of storing only the current state of data, all changes to the state are captured as a sequence of events. The system's state can be reconstructed at any point by replaying the events.
    • Benefits: Provides a reliable audit trail, supports scalability, and allows for building event-driven architectures.
Bulkhead Pattern:
    • Pattern: Bulkhead Pattern
    • Description: Segregates components into isolated pools to prevent the failure of one component from affecting others. For example, thread pools can be used to isolate requests to a specific microservice.
    • Benefits: Enhances system resilience by isolating failures and limiting their impact.

Choreography vs. Orchestration:
    • Pattern: Choreography and Orchestration
    • Description: Defines how microservices collaborate to achieve a specific goal. Choreography is a decentralized approach where each service communicates directly with others. Orchestration is a centralized approach where a central component (orchestrator) coordinates the interactions.
    • Benefits: Flexibility with choreography and centralized control with orchestration.

API Composition:
    • Pattern: API Composition
    • Description: Instead of relying on a single microservice to fetch and aggregate data from multiple sources, each microservice retrieves and composes its own data through API calls. This pattern helps maintain independence and scalability.
    • Benefits: Reduces dependencies between microservices, allowing them to evolve independently.

API Composition Patterns

Aggregator Pattern

One component calls multiple microservices and aggregates data.

Ideal for:

  • Dashboard APIs
  • Mobile apps

Strangler Fig Pattern

Used for migrating monolith → microservices.

Gradually replace old modules with new microservices.

Anti-Corruption Layer

Protect microservices from legacy systems.

Example:

  • Converting old SOAP response → REST JSON
  • Data format mapping



Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)