Microservices Architecture Style (MSA)

Microservice architecture style is about creating smaller services which are:
  • Independent & Autonomous
    • Loosely coupled and stateless so that can be developed, changed and deployed independently.
    • Backward compatible and honor service contract.
    • Support concurrent development.
    • Technology agnostic.
  • High Cohesion
    • Focus should be on single thing and having single responsibility.
  • Resilient
    • Embrace failure and designed for known failure.
    • Main reasons for failure are invalid input, exceptions, delay and unavailability of resources.
  • Observable
    • Centralized monitoring and logging.
  • Scalable and Maintainable
    • Microservices should be highly scalable and maintainable.
  • Automation
    • CI, CD along with TDD or ATDD.
Microservice Architecture

Challenges in MSA

  • How to identify the number of microservices and define their scopes?
    • Use Business technical capabilities map along with DDD patterns and event storming session (for more, click here)
  • How to retrieve read data from multiple services?
    • API Composition patterns can be used to render UI where aggregated data is required from multiple services.
    • CQRS: In this approach, create separate databases/tables for query (GET operations) and commands (POST, PUT, PATCH, DELETE operations) where data can be synchronized by using event driven approach.
    • Cold centralized data: Use this approach when real time data is not required. Export “hot data” (transactional data) into “cold data” (de-normalized data) in a centralized database for reporting or analysis, etc. Scheduler/batch job is common synchronization approach.
  • How to achieve data consistency?
    • Eventual consistency can be think-of instead of true consistency and to achieve it consider event driven communication and publish-subscribe system with Compensating Transaction Pattern.
  • Communication across microservices boundaries?
    • If the Ordering microservice in turn calls additional microservices using HTTP within the same request/response cycle, you’re creating a chain of HTTP calls. It might sound reasonable initially which may eventually results in chatty I/O.
      • Domain related microservices should not know the existence of other services.
      • Use only asynchronous interaction for inter-microservice communication, either by using asynchronous message- and event-based communication, or by using (asynchronous) HTTP polling independently of the original HTTP request/response cycle.

Leave a Reply