Building Microservices: A Reactive Framework Comparison

Most of us have heard the buzz about microservices and their benefits. In a previous post, I discussed microservices and when it may make sense to orchestrate vs. react when implementing them. If you choose to react, there are a number of options available. Reactive programming is a hot topic right now as both Java 9 and Spring Framework 5 were recently released and have reactive capabilities built in. There are many additional options for reactive programming depending on your use case. I tend to think of them in four different categories.

  • Javascript libraries such as Angular.js, React.js, Ractive.js, or Node.js that can be used to build front-end reactive applications.
  • Languages that have native reactive capabilities. We mentioned Java 9 and Spring Framework 5. Several others (but not limited to) include Clojure, Scala, and GoLang.
  • Reactive frameworks that run on top of the JDK and implement the reactive streams specification (which we will discuss in a bit) such as Project Reactor, Akka, Vert.x, and Ratpack.
  • Reactive Extensions also known as ReactiveX that provide many reactive capabilities for many languages with one of the most popular being RxJava

There are some key principles that each of these categories is centered around. In 2013, the Reactive Manifesto was written, establishing the four key principles of reactive systems: Responsive, Resilient, Message Driven, and Elastic

flowchart showing relationship between 4 blue squares using blue lines and blue arrows

graphic from

Reactive systems should be responsive meaning they should always respond in a timely manner. They should be resilient meaning they should remain responsive when failure happens. They should be message driven and enable asynchronous message passing that establishes a boundary between components (which can help keep them de-coupled and location transparent). Lastly, they should be elastic to enable components to dynamically scale and contract based on the workload demand, efficiently using resources.

In late 2013, another key piece of work began regarding the Reactive Streamsspecification. The main benefit with this specification is it enables reactive libraries that implement it to be interoperable. Specifically, it enables the sequences, cancellation, and backpressure to be composed across library boundaries while allowing the end-user to switch between implementations at their desire. Reactive Streams was released in April 2015, and became part of JDK9 in 2017. There are several reactive frameworks that run on top of the JDK and implement the Reactive Streams specification such as Project ReactorAkkaVert.x, and Ratpack.

According to, Akka had its first commit in 2009, Vert.x and Reactor in 2013, and Ratpack in 2014. Akka and Vert.x are two commonly used reactive frameworks that run on top of the JDK. Let’s take a deeper look at both and compare/contrast them across the below dimensions:

  • Microservice hierarchy and inter-communication
  • Delivery mechanisms & recovery capabilities
  • Open source perspective and supported languages
  • Add-on components along with monitoring options
  • Microservice Hierarchy and Inter-Communication

Earlier I mentioned the message driven principle of the Reactive Manifesto, which enables asynchronous message passing between microservices. Both Akka and Vert.x provide a built-in messaging mechanism that has similarities and differences. First, we should discuss the hierarchy paradigm as this is a significant difference between the two.

Akka is built off the actor model (originated in 1973 per Carl Hewitt) which provides a model for handling concurrent computation. In Akka, the unit of execution is the Actor and your microservices are built as actors. An actor is lightweight and there can be several million actors per GB of heap memory. The actor is an object that encapsulates state and behavior, and communicates exclusively by exchanging messages which are placed into the recipient’s mailbox. Below is a diagram that illustrates this.

flowchart made of blue, red, and purple rectangles, arrows, envelopes, and circles and black text

Akka Actor System

Actors are part of an actor system and can be arranged in a hierarchy. Below is an example of creating a top-level actor in an actor system:

lines of code written in black, purple, red, green, and blue

Example is from

This means they can split up and delegate tasks to child actors. The child actor is supervised and delegate their failure back to their parent actor. Actors can send messages to other actors in either a request/response pattern known as an “ask” or in a fire and forget mode known as a “tell”. Below is an example of an ask:

lines of code written in black, purple, red, green, and blue

Example is from

Vert.x is based on a flat hierarchy and does not implement the actor model. Instead, it is based on the event loop model. This is one of the first differences to call-out from Akka.

The unit of execution in Vert.x is known as a Verticle. It processes incoming evveents over event-loops, which are typical in asynchronous programming models. Below is a diagram that illustrates this:

small rectangles in shades of grey stacked into 1 large vertical rectangle, with grey orange and purple dots above it in a line, feeding into the rectangle in a process loop. purple arrows and grey text show that the loop repeats

Diagram is from

Now let’s look at this in code:

square rectangle containing lines of code written in white, red, and orange

Example is from

A verticle is passed configuration information and can be deployed multiple times, as seen below:

flowchart with large gear in center and arrows pointing to small gears, and purple/grey/red dots in a line feeding into the smaller gears as if they were in a processual loop. purple arrows and grey text help show the process looping and an orange document icon and orange arrow point to the large grey gear.

Diagram is from

Like Akka, Vert.x provides an internal messaging mechanism through the event bus, which is how verticles communicate through asynchronous message passing:

flowchart of 2 grey gears with orange and purple arrows pointing to a 2 large interlocked purple arrows. yellow circles scattered around the chart show steps 1, 2, and 3 and there are orange and purple envelopes and a grey cylinder for each step.

Diagram is from

How the verticles communicate is another difference to call out between Akka and Vert.x. In Akka, inter-communication between actors can happen with the ask and tell methods, which are point-to-point, meaning an actor must know who it wants to send a message to. Akka does also have an out of the box publish and subscribe capability that uses an EventStream construct. Publish and subscribe means a message can be published to the event stream without the publisher knowing who is going to receive the message. In this approach, Actors subscribe to channels that equate to objects (in Java), so an actor specifies a specific class to receive any message of that class or sub-class.

Similar to Akka, Vert.x also supports point-to-point and a publish-subscribe pattern. A difference is the message passing of Vert.x is language agnostic and uses JSON to pass data, whereas Akka uses specific objects from either Scala or Java. Additionally, the subscriber in Akka needs to know the class of the object it wants to receive, where in Vert.x that is not necessary. Below is a Vert.x example:

Register Event Handler:

lines of code written in black and blue


lines of code written in black, blue, and dark red


lines of code written in black and blue

Delivery Mechanisms and Recovery Capabilities

Being resilient is another principle taken from the Reactive Manifesto. How well can something recover from a failure state and continue to be responsive during that time?

Akka provides an additional component known as Akka Persistence that can be used to store the internal state of an actor. This enables the state of an actor to be recovered if it crashes. Akka persistence uses an event sourcing pattern, which stores any changes to an actor’s state in an event store. Events in the event store are immutable. The actor is recovered by replaying the events from the event store.

Below is an Akka Persistence example from the website that supports event sourcing with the AbstractPersistentActor class. The persist method is used by an actor that extends this class to persist and handle events. The behavior is defined by implementing createReceiveRecover and createReceive.

lines of code written in blue, black, and dark red

code example from

lines of code written in blue, black, and dark red

code example from

Currently, Vert.x does not provide out-of-the-box recovery capabilities. From a message delivery reliability standpoint, Akka provides at-most-once out of the box and provides at-least-once when Akka Persistence is leveraged. Similar to Akka, Vert.x provides at-most-once, but does not provide capabilities for at-least-once. At-most-once means that data loss is possible. At-least-once guarantees the message will be delivered at least one time at a minimum.

From a message ordering perspective, Akka can guarantee message ordering when one single actor directly sends a message to another actor using the tell operator. If there are multiple actors sending messages to a common destination, they will be ordered per sender, but there are no global ordering guarantees. Vert.x will also deliver messages to any handler in the same order that they were sent from a particular sender.

Open Source Perspective and Supported Languages

Both Akka and Vert.x are open source projects. Akka supports Scala and Java while Vert.x supports Java, Groovy, Ruby, JavaScript, Ceylon, Scala, and Kotlin.

From a maturity perspective, Akka has been around the longest, having started in 2009 and is 8.5 years old at the time of this article. Vert.x started in 2013 and is around 4 years old at the time of this article. Lightbend is the main company that provides the core contributors for Akka, while RedHat has a number of full-time developers working on Vert.x.

As of September 2017 on, Akka has very high activity with 1554 commits in the last year and 601 total contributors:

openhub dashboard showing 4 graphs - one on left has waves filled in in blue, grey, and green and smaller circular pie chart on bottom in purple and green; one in middle and on right shows wave spikes using blue lines

dashboard from

Vert.x also has high activity with 704 commits in the last year and 124 total contributors:

openhub dashboard showing 4 graphs - one on left has waves filled in in blue, grey, and green and smaller circular pie chart on bottom in purple and black; one in middle and on right shows wave spikes using blue lines

dashboard from

Add-on Components and Monitoring Options

Earlier I mentioned the Akka Persistence component that can be used for additional recovery capabilities. Akka also has additional components including, but not limited to, Akka Clustering and Akka Streams. Akka Clustering helps with the location transparency aspect of actors. If an actor needs to send a message to another actor, it uses an ID (instead of an ActorRef) and Akka Clustering takes care of routing that message to the right cluster. If an actor dies, clustering will take care of restarting that actor. Akka Streams is a streaming abstraction on Akka actors. Dean Wampler has a presentation that compares Akka Streams to other streaming technologies. He mentions it is good for low latency and complex event processing use cases. Akka Streams can handle very high volume in terms of the number of messages it can process per second and it has good support for parallelization of workloads, but it doesn’t support distributed materialization like Spark and Flink do. With Vert.x, there are not any additional components.

From a monitoring perspective, DataDog (see screenshot below) and OpsClarity are at least two options for monitoring Akka.

datadog dashboard with multiple rows of small graphs in blue, green, orange, and red. column on left contains large numbers written in blue, and top 2 squares from the right are menus with blue rows

Diagram taken from

With Vert.x, there are several options, including Hawkular (see screenshot below) and DropWizard (JMX).

dashboard showing menu with black, red, yellow, green, and orange square icons next to black text. one menu option is selected which opened an orange, green, and red scatterplot and green pie chart in a separate window

Diagram taken from


In this article, we discussed some historic context for reactive programming while also touching on some of the many similarities and differences between Akka and Vert.x. In general, some of the reasons to use Akka vs. Vert.x include:

  • Prefer to use the Actor hierarchy model for your microservices
  • Are good with using language specific objects to pass message data between Actors
  • Need the recovery and persistence capabilities that come along with Akka Persistence so the internal state of an actor can be persisted and recovered in the event of a crash
  • If you need at-least-once delivery (Akka Persistence)

In general, some of the reasons to Vert.x vs. Akka include:

  • Prefer to use a flat hierarchy and not the Actor model
  • Prefer to use language neutral JSON vs. language specific objects when passing message data
  • Need wider support for languages outside of Scala and Java (i.e. Groovy, Ruby, JavaScript, Ceylon, Kotlin)
  • Are good with at-most-once delivery (which can result in message loss)

The specific needs of your project will help you determine which one is the right choice for you and I encourage you to do a prototype on each. The good news is — both implement the Reactive Streams specification which means you can use them together if that option makes sense for your use case.

Note — The analysis in this article was based on Akka 2.5.4 and Vert.x v3.4.2

Andrew Bonham, Senior Distinguished Engineer/Architect

Senior Distinguished Engineer with a passion in microservices, open source, cloud, reactive architectures. business process management, and rules engines.

Related Content