Experiments

microservices_design_pattern

6 min read

Microservices Design Pattern

Common Patterns

  • Decomposition
    • Domain-based microservices
    • Business process-based microservices
    • Atomic Tx-based microservices
    • Strangler
    • Sidecar
  • Database
    • Database per service
    • Shared Database per service
  • Data
    • CQRS
    • Saga
    • Event Sourcing
  • Integration
    • API Gateway pattern
    • BFF pattern
  • Cross Cutting Concerns
    • External Configuration
    • Discovery:
      • Service Registry
      • API Gateway
      • Client Side Discovery
      • Server Side Discovery
    • Circuit Breaker pattern
  • Observability

    • Logs

    • Metrics

    • Distributed Tracing

    • Health Check

API Gateway Pattern

  • Provides a centralized entry point for managing interactions between clients and application services.
  • Stores API contract and version control
  • It performs following:
    • Gateway Routing:
      • Acts as a reverse proxy
      • Routes client requests to appropriate services
    • Gateway Aggregation:
      • Aggregate multiple client requests into a single request.
    • Gateway Offloading: provide cross-cutting functionality
      • SSL termination
      • Mutual TLS
      • Authentication
      • IP allowlist or blocklist
      • Client rate limiting (throttling)
      • Logging and monitoring
      • Response caching
      • Web application firewall
      • GZIP compression
      • Servicing static content
  • https://learn.microsoft.com/en-us/azure/architecture/microservices/design/gateway

Strangler Pattern

  • aka Strangler Fig
    • Because Strangler Fig Tree grows on host tree often resulting in host’s death
  • Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services.
  • Initially you can pass 10% load of web requests to the microservices and 90% on legacy monolithic service
  • If failure happens we can make microservice load to 0%
  • If success we can incrementally increase load towards 100% and finally decommission the legacy monolithic service
  • Uses
    • migrate legacy system by breaking down monoliths
  • https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig
  • https://java-design-patterns.com/patterns/strangler/

Database management in microservice

  • Database management in microservice
    • each service has its own DB
    • all service has shared DB
  • shared DB disadvantages:
    • scaling with demand of each microservice is not good since shared need to be scaled even though only one microservice has high demand
    • same table might be used by different microservices, hence modification can cause issues
  • shared DB advantages:
    • JOINs are easily handled
    • transactions are easily handled (ACID)
      • assume I need to insert into 10 tables, then I can perform transaction easily and in case of failure can rollback
  • DBs per service
    • SAGA pattern helps perform transactions (ACID)
    • CQRS pattern helps distributed DBs perform JOINs

Sidecar Pattern

  • aka Sidekick pattern
    • Resembles a sidecar attached to a motorcycle.
  • Deploy components of an application into a separate process or container to provide isolation and encapsulation.
  • Provides supporting features for the parent application
  • Shares the same lifecycle as the parent application (creation, deletion)
  • Examples
    • Infrastructure API
      • Infrastructure team creates a service alongside each application which performs logging, environment data, configuration store, discovery, health checks, and watchdog services
      • the sidecar also monitors parent application’s host environment and process and logs the information to a centralized service
    • Deploy Ambassador as sidecar
    • Deploy Nginx reverse proxy as sidecar
  • https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar

Ambassador Pattern

Anti-corruption Layer Pattern

  • Implement a façade or adapter layer between different subsystems that don’t share the same semantics
  • first described in Domain-Driven Design by Eric Evans
  • Uses
    • A migration is planned to happen over multiple stages, but integration between new and legacy systems needs to be maintained.
    • Two or more subsystems have different semantics, but still need to communicate.

CQRS

Event Sourcing

  • https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing
  • Instead of storing just the current state of the data in a relational database, store the full series of actions taken on an object in an append-only store.
  • Command Handlers
    • Calls the event store to get the historical events for the entity
    • Events are played back in the object to materialize the current state of the entity
    • The business logic is run and events are raised
  • It is relatively expensive to read and replay events
    • applications typically implement materialized views
  • Often combined with CQRS Pattern
  • Advantages
    • Events are immutable and can be stored using an append-only operation
    • Can help prevent concurrent updates from causing conflicts because it avoids the requirement to directly update objects in the data store
    • Provides an audit trail to monitor actions taken on entity
  • Disadvantages
    • It is complex to implement and should be avoided
    • Eventual Consistency
    • Current state of an entity can be determined only by replaying all of the events
    • Consumers must be idempotent to avoid re-applying same update

  • Examples

Bulkhead Pattern

  • aka cell-based architecture
    • Named after the sectioned partitions (bulkheads) of a ship’s hull
    • If the hull of a ship is compromised, only the damaged section fills with water, which prevents the ship from sinking
  • Application design that is tolerant of failure
  • Elements of an application are isolated into pools so that if one fails, the others will continue to function
  • Partition service instances into different groups, based on consumer load and availability
    • Consider deploying them into separate VMs, containers, or processes.
  • asynchronous messages can be isolated through different sets of queues
    • Each queue can have a dedicated set of instances

Messaging Bridge Pattern

  • Integrate disparate systems that are built on top of different messaging infrastructures
  • old system with old message queue ⇐-⇒ message bridge ⇐⇒ new msg queue ⇐→ new system

Blue-Green Deployment

  • Two identical environments, referred to as “blue” and “green,” are set up.
  • One environment (blue) is running the current application version and one environment (green) is running the new application version.
  • Once green environment is tested, the live traffic is directed to it, and the blue environment is used to deploy a new application version during next deployment cycle.
  • Reduces the risk associated with deploying new versions of an application