Reactive Microservice app in Java Spring Boot

I used to do Java for about 7 years from 2018 to 2005 but have been pretty much .net since then. So I missed out on the “spring craze”. Being that I’m really interested in microservices and saw there was a course on Pluralsight about the Reactive Manifesto, I was interested in it. Examples were in Java so I thought it would be a good refresher. Java itself does not give me the difficulties. It’s setting up the IDEs (Eclipse and/or Intellij) along with mvn as that’s a bit different than how it’s done in .NET/C# 🙂

A video on this is coming up but here are notes.

Architectural Patterns

Hexagonal Architecture – Ports and Adapters
Programming to an interface (see as an electrical outlet)
Several db’s but same port

Layered Architecture
Multiple components arranged in a stack
Presentation
Integration
Business
Database

Monoliths
Still effective today. Single units implemented as layered architectures.
Continuous delivery is difficult
Cascading failures affecting all segments

Microservices
Single responsibility model. Hexagonal approach with each microservice a port with the corresponding client/adapter.
Modular components.
S
Isolated DB with a “shared nothing” architecture.
Requires careful coordination.

Reactive Manifesto Published in 2014

Responsive
Respond in a timely manner
Resilent
Systems ability to stay responsive in the event of failures
Elastic
Ability to stay responsive under increasing load
Message Driven
Loose coupling between services establishing boundaries between service components…

Idempotency

Repeating the same operation does not cause adverse affects of the state of the system/resource. It’s important to examine state of the resource on each request to determine if the operation is valid.

Can be achieved by a correlation ID – predefined mechanism to de-dup operations as they come in.  It can be a “check#” or some other predefined ID.  Correlation ID’s are ALWAYS independent of the request (ie, AWS S3 uses an etag).

React Manifesto – Responsive

Timely responses against customer interaction
Consistent and reliable upper bounds are established to increase Qos and customers expectations.
Small independent services that are “designed to fail”.

“What you can measure, you can improve”.
First byte latency – how long a customer waits on a page load before he/she sees something. Cloudfront, etc..
Service and client side metrics
Cloudwatch – aws sdk can be configured to send request/response metrics per service interaction.

React Manifesto – Resilient

Systems ability to stay responsive under failure.
Achieved by:
Replication
Execute multiple copies of a give task in parallel. Load balancer helps.
Single request failure does not affect other services. Autoscaling groups.
Containment and Isolation
Supported by decoupled architecture (messaging)
https
Microservice decoupling occurs by https
Delegation
Execution responsibility passes from one component to another.
Each component does its own work.

Resilience – In Practice

Circuit Breaker Pattern
Contains and isolates a delegated services failures preventing resource exhaustion
Turn off communication to a service (switching circuit on) for a while to allow the service to “catch up” before turning the communication back on (switching circuit off)
Histrix (netflix library)

Bulkhead Pattern
Same as above
General for DB communication where different api uses different connection pools.
ie, connection pool A may be turned off but B remains on.

Asyncronous message passing

How about error handling?  How do we deal with that?

Logging

Distributing tracing

– Correlate logs about a single operation as the operation flows thru various different microservices.   Use a “Correlation Id”.  You can pass that onto other requests thru HTTP headers, etc..

React Manifesto – Elastic

This is NOT scalability. Scalability is the measure of the component’s ability to handle an increased workload.
Elasticity – 2 way scalability. Shrink and Grow. Allocating/deallocating.
Sharding, replicating and workload distribution.

Elasticity in Practice

S3
Read/Write shards in DB

React Manifesto – Message Driven and non-blocking

Protocol where applications and architectures can be decoupled from one another allowing for clean evolution, isolation, containment and delegation of tasks.
Optimizes system resources by concurrency.

Security

Employ the least privilage model in microservices. Single responsibility.

Event Sourcing

Persist every change to application state. 
Git
Text editor session (where you can “undo”)

Pros
Auditing done to perfection
Cons
Incur large storage costs
Capturing can be very complex

Event Sourcing should be local to each bounded context

Bounded Context (BC)

Logical boundary (microservice usually)
Each BC maintains control over its own resources and that no external process knows about our applications “inner workings” (sounds like “Class” in OO lingo).

Each app shares a global event store (history of BC events)
Outside apps that are interested will publish/subscribe to these events

Global Event Store

ActiveMQ, Amazon SQS, RabbitMQ, Apache Kafka, etc..

For Kafka, for example
Topics – Create a topic per domain event.
Partitions – Guaranteed message ordering/durability (like a queueGroupName in nats streaming service).
Apache Zookeeper – battle tested coordinating distributing services. Store cluster-wide configuration.
Confluent Schema Registry

Sagas and Distributed Transactions (incepted in 1987)

Addresses the ability to rollback a “logical transaction” that spans multiple bounded contexts.
Complex to implement.

Attempt to break resource exhaustion.
Break long term transactions into smaller transactions.
Sequence of transactions local to BC

Types of sagas
– Choreographed
Global event store where services Publish/Consume events
Transaction failed should send messages to other services to trigger rollback to the series of transactions (with the same correlation id) that were processed recently
– Orchestrated
Focused on commands.
Publish commands (not events)
Consumers listen and act
Rollbacks are the same.

Finite State Machines – A way to implement sagas.
States
Begin in an initial state
Conditions
Transitions
Inputs

Decomposing

– break monolith into microservices. It’s more of an art than a science. There is no formula.
Strategies include:
* By business capability (ie, Payment service)
* By domain objects – the Order Service (services over domain object ‘Order’)
* By Action Verbs – Order Service
* By Noun Verbs – Customer Service or Company Service
SRP – Single Responsibility Principle
* Do one thing and do it well.
– You want smaller teams responsible for their own microservices but it’s not always feasible.

The Twelve-Factor App
12factor.net
 

The test application

– Upload a document (a text document)
– Translate the document to another language. Source/Target language + completion date.
Submit document for translation and lock the document.