Announcing Akka 24.05: More Security. More Performance. More Efficiency. Watch the Webinar Replay
reactive resilience scalability event-driven akka play lagom

Ask Lightbend Anything: When Do You Know It’s Time To Build A Reactive Application?

Ask Lightbend Anything: When Do You Know It’s Time To Build A Reactive Application?

In this Ask Lightbend Anything blog series, my colleague Alexander Golubyev, Senior Consultant at Lightbend, compiled a list of the most frequently asked questions from our conversations with hundreds of enterprises. In our previous ALA, we discussed how to choose which application to rewrite using a Reactive approach.

But what about when? When do you know it’s time to build a Reactive application?

Many of you have probably already seen the Reactive Manifesto, signed by over 24,000 people and crafted by experts like Lightbend co-founder and Akka creator, Jonas Bonér. For those who haven’t checked it out yet, the Manifesto sets out 4 key principles for building systems that react to modern demands on distributed services at scale.

  • Responsive - the system responds in a timely manner
  • Elastic - the system stays responsive under varying workloads
  • Resilient - the system stays responsive in the face of failure
  • Message Driven - relying on asynchronous, non-blocking message-passing

I know what you’re thinking; the change to asynchronous processing, stateful, data-driven services, and a cloud-native microservices architecture is not easy at any given time. There are challenges that you’ll face along the way.

For example, the architecture of your Reactive system will need to be based on the principles of Domain Driven Design (DDD), and include event sourcing and CQRS. You will also need to understand how data persistence works with eventual consistency (vs strong consistency) and duplicated data. These approaches are slightly different than standard DAO/Service/MVC and definitely require an open mind and focus on Reactive goals.

So it’s important to consider whether it’s time to bother making your system Reactive, because it’ll require a change in thinking and additional effort…

When To Make The Switch To Reactive

When do you need to take a closer look at whether your systems are in need of a Reactive transformation? What triggers do should you be looking for? Here is a short list of requirements that may resonate with you:

  • Your application needs to be horizontally scalable to tens or hundreds of nodes (read about Verizon)
  • You need to have much shorter development-to-production cycles (read about Walmart)
  • You need to reduce service downtime due to a lack of failure isolation (read about Norwegian Cruise Lines)
  • You need to increase performance/throughput for a single node:
    • Introduce asynchronous processing for messages/requests
    • Avoid race conditions and concurrency bugs in your application
  • You need to pump big data from a datalake or another database or service as fast as possible (read about HPE)
  • You need to reduce the complexity of a monolithic application (read about Capital One)
  • You need to scale drastically direct services within your monolithic application
  • Your ACID database is a bottleneck as too many application servers are working with it
  • You need to add cluster sharding to improve scalability of services (read about Vivint Smart Home)

Here you can solve each problem separately with a solution of your own design; however, if you have several of these requirements, it may be easier to use a platform or framework that can aid in developing your application in a Reactive manner.

Tools For Going Reactive The Smart Way

With a subscription to Lightbend Platform, you can design, build, run, and manage your Reactive microservices architectures and real time streaming applications. In addition to enterprise features and full application lifecycle support, the Lightbend Platform includes the following open source technologies:

  • Akka naturally introduces asynchronous message processing so you don’t need to worry about synchronization issues.
  • Play helps with service HTTP pages with the Reactive approach in implementation.
  • Lagom is a framework for building microservices in a Reactive way from scratch.

These technologies can really help in building out your Reactive applications, but it’s important to recognize these triggers in the previous section before making a commitment to go Reactive.

Once that decision is made, you can consider using new development patterns (i.e. DDD, asynchronous messaging), new approaches (CQRS, event sourcing), and platforms and frameworks (Lightbend Platform, Akka, Play, Lagom) that will help you in shifting gears to make your application Reactive.

Related ALA Blog: Which App Should We Rewrite?

If you weren’t able to check out the first blog post of the Ask Lightbend Anything series where we discuss how to choose which application to rewrite using a Reactive approach, you can view it here:

As always, Lightbend is here to help. If you’d like to contact someone at Lightbend, or request a demo of Lightbend Platform, just let us know:


The Total Economic Impact™
Of Lightbend Akka

  • 139% ROI
  • 50% to 75% faster time-to-market
  • 20x increase in developer throughput
  • <6 months Akka pays for itself