dhana-git

Guide on Microservices - Avoid synchronous communication

---

• Many microservices are based on REST interfaces. However, the perceived simplicity of REST services can easily backfire when you take availability into account.
• Consider a system of N microservices that depend on each other via REST calls. This system only works if all microservices are up and running. In other words, this system does NOT work if at least one of these microservices is down or unavailable. The risk of this happening becomes much higher as N grows.
• There are patterns like the "circuit breaker" and other tricks to fall back to some reduced level of operation, but this greatly complicates the code and the development of these systems.
• Instead, what you can do is favor asynchronous communication via, say, messaging over queues. The light-weight brokers that just allow you to send a message to a remote consumer. If the remote consumer is down, no problem: the message will be queued until the consumer comes bac

dhana-git

Guide on Microservices: Backups and Consistency | Consistent Disaster Recovery for Microservices - the BAC Theorem

---

The BAC (Backup Availability Consistency) Theorem

When backing up an entire microservices architecture, it is not possible to have both availability and consistency.

• Eventual Inconsistency with Full Availability (High Availability)
  • When making an independent backup of the state (the event log) of each service, it is possible that one service will be backed up before the event is added to the log, while the other service will be backed up after the corresponding event is added to its log. When restoring the services from backup, only one of the two services will recover its complete log. The global state of the microservice architecture will thus become inconsistent after restoring it from backup.
  • Possible problems,
• Broken link

dhana-git

• Design Principles Overview (https://gist.github.com/dhana-git/675d837251b9b8cd4a7a4122695d182c)
• Anemic Domain Model (Anti-pattern)
• Code Smells
  1. Ref “Chapter 3. Bad Smells in Code” in “Refactoring: Improving the Design of Existing Code by MartinFowler” book.
  2. http://wiki.c2.com/?CodeSmell
  3. https://sourcemaking.com/refactoring

dhana-git

Microservices API Versioning Strategy

We try to define the right schema/contract for each message/interaction at first, APIs certainly evolve and grow over time, new requirements are introduced, and eventually, also data schema requires changes; hence unlikely we would end up adding a breaking change.

Define the "API Contract" first, if you change the contract, it will impact your consumers.

Context

API

APIs are mechanisms that enable two software components to communicate with each other using a set of definitions and protocols.

API stands for Application Programming Interface.

dhana-git

MACH (Microservices API-First Cloud-Native Headless) Technology Stack

Introduction

• MACH is an industry stack describing modern best-in-class technologies and services.
• MACH Architecture is a set of principles and patterns that define the different building blocks of new, pluggable, replaceable, scalable, independently-deployed and continuously-improved components for creating back-end services and modern user experiences.
• More focused on composable solutiions.
• History: https://machalliance.org/insights/a-little-history-of-technology-leading-to-mach

1. Microservices Based

• Individual pieces of business capabilities (bounded contexts/domains) that are loosly coupled, single responsible, self contained, scalable, resilient, independently developed, deployed, and managed.

2. API-First

dhana-git

Event-driven architecture (EDA) is an architectural style where decoupled microservices can asynchronously exchange events as they occur via an event broker.

EDA is more loosely coupled than the client/server (request-response) paradigm because the component that sends the message doesn’t need to know the identity/existence of the receiving components at the time of compiling.

An event-driven architectural pattern can be implemented via RabbitMQ, Kafka, and IBM MQ message brokers for B2B service-to-service interactions to achieve the following goals,

• All the Inter-Process Communications (IPC) occurring over MQ (RabbitMQ Broker) within the boundary of microservices use it to replicate/relate the domain data.
• Reduce the amount of data exchanged between components. E.g. Front-end/BFF components are not required to send whole data to the micoservices on the subsequent calls if they have already made relevant calls as part of previous interactions.
• Achieve low latency and high throughput by pro-active pro

dhana-git

Schema Registry

A schema registry lets you store schema information in a textual format and makes that information accessible to various applications that need it to receive and send data in binary format.

A schema is referenceable as a record consisting of a subject that is the logical name of the schema, the schema version, and the schema format, which describes the binary format of the data.

The producer consults the registry to establish the correct schema ID when sending a message, and the consumer uses the registry to fetch the sender's schema.

With this solution, we try to move the schema resolution to a central service. It can remove some of the consumer versioning issues, as they will request the schema on demand from a centralized service and apply it dynamically, it can also introduce significant complexity, need for a framework, and a possible availability problem to the system.