Microservices

Patterns

Application architecture patterns

  • Monolithic architecture
  • Microservice architecture (opens in a new tab)
    • Pros
      • Continuous delivery of every service built and maintained by different teams without blocking each other
      • Scalability
      • Availability
      • Every service is platform independent, and can be implemented with any technology, no vendor lock-in, and no commitment to any tech stack
    • Cons
      • Operational complexity
      • Difficulty in implementing collaboration among services
      • New technologies leads to skills shortage

Core microservice development pattern

  • Service granularity
  • Communication protocols
  • Interface design
  • Configuration management
  • Event processing between services

Routing patterns

Client resiliency patterns

Client-side load balancing

Circuit breaker (opens in a new tab)

Fallback pattern

Bulkhead pattern

Security patterns

Observability

  • 3 pillars of observability (opens in a new tab)

    • Metrics

      Statistics drawn from raw logs, providing an overview of a certain aspect, so you can read trend or get a general idea of the system.

    • Logging

      Records of events, but not neccessarily specific to a certain context, like independent dots.

    • Tracing

      Connecting dots together under a certain context into a line, so you can understand how the whole event happened from the beginning to the end.

  • Resources

Log aggregation (opens in a new tab)

Use a centralized logging service that aggregates logs from each service instance.

Audit logging (opens in a new tab)

Distributed tracing (opens in a new tab)

Build and deployment patterns

Data management

Database per service

  • Each service has its own database server.
  • The service’s database is effectively part of the implementation of that service, therefore cannot be accessed directly by other services.
  • This pattern can help ensure atomicity of transactions and data consistency within a service.

CQRS (Command Query Responsibility Segregation) (opens in a new tab)

  • Separate the read and write operations of a data store

  • Data is replicated from the write store to the read store

  • Pros

    • Better performance, scalability, and security

  • Cons

    • Lag in consistency between the read and write stores because of the replication
    • More complexity in the architecture

Event sourcing (opens in a new tab)

  • Application state is stored as a sequence of events.

  • An append-only event store (event log) is used to record the full series of events that describe actions taken on data in a domain.

  • The current state of the application is derived from the event log and can be replayed to any point in time.

  • This log-based approach enables distributed transactions such as the saga pattern.

  • Cons

    • Need to design event schemas and manage the event store
    • Schema evolution requires careful planning

  • Resources

Saga (opens in a new tab)

  • A sequence of local transactions that are coordinated by a saga orchestrator
  • Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga.
  • If a local transaction fails, the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.
  • 2 common saga implementation approaches, Choreography and Orchestration
  • With Choreography, participants exchange messages via the message broker for coordination.
  • With Orchestration, an orchestrator (another service) coordinates the participants.

Transactional outbox (opens in a new tab)

  • Ensure that updates to the application state (stored in tables) and publishing of the respective domain event is done within a single transaction.
  • CDC can be used to capture the domain events and publish them to the message broker.

Service interface design

  • Embrace the REST philosophy

  • Use URI’s to communicate intent

  • Use JSON for your requests and responses

  • Use HTTP status codes to communicate results

Service Mesh

Istio

References

Java 9TypeScript