When Services Have a Need for Speed…
Reactive Microservices Can Be the Answer!
When you need high performance, low latency, reliability, and scalability — reactive microservices are the 21st Century answer to your problem. Why not take a few minutes to see why?
For years we’ve been building synchronous, request-response applications using popular SOA technologies like Spring Boot and Jakarta RESTful Web Services. But today, here and now in the 21st Century, those 20th Century technologies are running out of gas when it comes to high performance, low latency, reliability, and scalability. We need to find a better way.
Microservices
Like many of you, we turned to the microservice architectural pattern to overcome some of these problems. We found that by itself the pattern was only addressing some of the issues — until we figured out the missing piece to the puzzle. The problem was that we were doing microservices the way we did SOA —using synchronous request-response APIs.
The Problem with Synchronous
Because microservices are loosely coupled and communicate via message passing — if that messaging is synchronous, the processing threads used will spend a lot of time waiting rather than doing work. Modern computers are so fast we tend to forget how many processing cycles an operating system consumes to manage threads. Context switching is a reasonably heavy duty exercise sometimes eating up more than 50% of a CPU’s cycles — cycles that are not doing the work of the application. That leads us to the missing piece of the puzzle, reactive microservices.
Reactive Systems
As described in The Reactive Manifesto, applications built as reactive systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive systems are highly responsive, giving users effective interactive feedback.
Reactive systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency. Asynchronous messaging is a key and common attribute in modern high-performance and high-throughput systems.
If you would like to know more about why reactive systems are so fast, this 17-minute YouTube video, What Are Reactive Systems?, is an excellent explanation of the advantages of reactive systems.
Reactive Actor-Model Microservices
The shape of a reactive microservice actor is determined by its primary purpose. At its very core a microservice actor is a reactive asynchronous message processor. It is shaped and optimized to use a single thread to process a single message at a time — as quickly and efficiently as possible. Very much like Node.js, it is a high-performance, asynchronous message processor.
The messages that a microservice is optimized to process are of the Representational State Transfer architectural style. There are three basic message categories: task (request), response, and error. Those messages can be delivered in one of two ways:
- As an asynchronous REST message.
- As an Event-Carried State Transfer or ECST event.
Messages are always sent asynchronously or published as events. There is no synchronous messaging. Every message is sent to a microservice logical address or published to an event topic. Every microservice actor has an attached mailbox that buffers input and output messages for it.
Wrapping Up
Asynchronous reactive actor-model microservices are a 21st Century technology for 21st Century requirements. Traditional request-response SOA APIs cannot meet the the performance, scalability, and reliability requirements of modern cloud-deployable applications without additional layers of API gateways, load balancers, and other CPU cycle-stealing add-ons. If this idea makes sense to you, we recommend reading:
