Reactive Microservices — 6

Kapil Raina

5 min readJun 16, 2021

This is an 8 part series on reactive microservices. [1 , 2 , 3, 4, 5, 6, 7, 8]

Part 2 , 3 , 4 & 5 of this services listed reactive microservices patterns. This part continues to list more patterns.

Traditional Microservices patterns also relevant in reactive microservices

Service Discovery

Usual Client and Server-side service discovery patterns apply to reactive microservices as well.
Some reactive platforms also enable peer-to-peer, eventually consistent manner to share the service location information (e.g. Netflix Eureka).
Location transparency is key to service discovery in reactive microservices.

API Management & Evolution

API & Protocol Versioning
Adapter & Anti-Corruption Layers
API Gateway

Circuit Breakers

Managing the faulty services & back-pressure is still a concern. Netflix Hysterix, Akka

Security

Authentication: Mutual Auth, HTTP-Basic, Tokens
Authorization: Token Grants, RBAC
Encryption and Message Signing: HMAC

Latency

Measuring latency and establishing the bounds of acceptable latency is even more relevant for reactive microservices since it directly impacts the responsiveness tenant.

Services must have bounded latency measured as percentiles.
Concurrency must be a first-class pattern to reduce latency.
Employing declarative pool sizes.
Employing circuit breakers to shield services from more requests
Usage of back-pressure techniques.

Failure Handling

Failures and application errors affect the resilience of the system which is a core tenant of reactive microservices. Owing to the distributed and async nature of reactive microservices, error handling is not simply a matter of handling exceptions since the execution would not be happening in the same thread.

Include error handling as a special event in the event-driven async processing.
In Reactive Steams, exceptions are first-class citizens. Error handling is built right into the Reactive Streams API specification
Use of bulkheads between services to isolate failure
Use of circuit breakers to protect the failing service from more requests
Delegate handling of failure to a different component than the service itself.
Fail-fast so that errors don’t affect responsiveness.
Error observability

DevOps & Automation

Containerization, Cloud, “Infrastructure as code”, delivery pipelines augment well with the distributed deployments of reactive microservices. The automation is critical for ops to effectively deal with hundreds of services. Few most relevant ones for reactive microservices:

Rolling Deployments/Blue Green Deployments
Predictive Auto-Scaling
Observability and Distributed Tracing
Pipelines

Reactive Systems & Domain Driven Design

Domain Driven Design has come to be associated with designing the event driven microservices and is considered a great starting point to identify the domain boundaries and create the bounded contexts. DDD naturally influences much of reactive microservices as well. The concepts borrowed from DDD sit well with developing reactive systems as well. Albeit DDD is not a pre-requisite to implement either microservices or reactive systems. These just have lot of common ideas though and fit perfectly well with each other, enough to unify them into Reactive-DDD.

DDD-Reactive-Microservices attempt to address uncertainty of distributed systems and complexity of business domain together in a single model and thought.

1. The core domain complexity still needs to be managed and modelled in reactive microservices. A good domain model is a basis of managing this complexity & avoiding big-ball-of-mud. Traditionally DDD focused on domain model(state) to determine the boundaries of a subdomain. Need of reactive Systems has led to Event-First Domain Driven Design with events(behavior) that define consistency boundaries. Event-First microservices enable message-driven tenant of reactive systems.

2. Events are part of the ubiquitous langue of the bounded context. Domain events encapsulate the behavior of the bounded context within a boundary. To understand the events and their causality is to understand the domain. Event Storming technique helps mine the facts of a domain.

3. The bounded contexts must be integrated to compose an application. Inside the bounded contexts, Aggregates produce facts i.e. Domain Events which aggregates in other bounded contexts should react to. Thus cross-aggregate integration is reactive. Events are also relevant within the boundaries of aggregate (aggregate event).

The popular technique to determine the bounded contexts using domain events is called Event Storming.

4. DDD Aggregates result into an isolated and autonomous microservices since aggregates encapsulate the state and behavior. Aggregates represent a bounded context and thus a potential microservice, that doesn’t depend on other services. Aggregate behavior is published in emitting and subscribing events which provide isolation, consistency and transaction boundary between services. The aggregate reflects the domain by logically grouping various commands, events, and reactions together.

5. In DDD, reactive behavior is also happening within the bounded context with techniques like CompletableFutures and Reactive Stream processing which take advantage of asynchronous, non-blocking & parallelism.

6. DDD Event Sourcing is a very mature technique to model the state and behavior of the subdomains. Event Sourcing along with CQRS are pervasive event-driven patterns that reactive microservices can use.

7. Reactive Microservices introduce below concepts that impact the user journey and system behavior. These aspects were hidden under abstractions in non-reactive designs but are now made explicit in the model. Domain experts and developers need to have a discussion on what these mean for a journey and agree on the consequences.

“Nature of Distributed Computing Should Be Part of Business Domain”

a. Eventual Consistency

b. Compensating Transactions to Handle distributed system’s uncertainty. “In a system that cannot count on distributed transactions, the management of uncertainty must be implemented in the business logic.”

c. Error Handling

d. Failure handling (e.g. Circuit Breakers)

e. Multiple and out-of-order message delivery

8. Message semantics in reactive microservices are modelled on DDD manifestations of the messages i.e. Command, Event, Query, which are known as “Domain Activities”. Messages themselves are modelled as Value-Objects.

9. Aggregates are distributable. In frameworks like Akka/Lagom, aggregates (as PersistentEntities) are sharded into partitions and provides abstractions to control consistency and availability.

10. Implementing ACL as Adapters in reactive microservices enables purity of domain and doesn’t have any dependency on the frameworks or protocols. This makes change of technology transparent to the domain.

11. The ContextMap provides a way to model the relationship between sub-domains and enables decisions in the architecture. For example. Impact on another bounded context in case of Customer-Supplier relationship. Should the events be versioned, and should the Customer be a tolerant-reader.

References: