This series will demonstrate how to build reactive systems. To accomplish this, we're going to rethink IBM's Stock Trader reference architecture as a reactive system from the ground up.


This series will introduce a cloud-native approach to designing mission-critical enterprise systems. To accomplish this, we'll use open source tools that can take advantage of virtually unlimited pools of resources in the cloud to create systems that are responsive, elastic, resilient, and message-driven.

On completion of the series, you should understand the fundamentals of reactive systems development and gain hands-on experience as we work together to implement a reactive systems architecture. This will enable you to create enterprise software that is responsive, scalable, and resilient under all circumstances, including hardware failure, spikes of traffic, and other acts of force majeure.

What is a reactive system?

The term reactive system originally comes from the reactive manifesto, a short set of guiding principles on how to build responsive, scalable, self-healing systems that are cloud-native.

A reactive system has a few specific properties:

  • Responsiveness
  • Elasticity
  • Resilience
  • Message-driven

A reactive system can provision resources on demand, such as additional virtual nodes in the cloud, and then spread the workload across those resources. This gives reactive systems the ability to scale out in real time to deal with fluctuating demand. A reactive system can also scale back in once demand subsides, an important but often overlooked trait of elastic systems. This helps you to keep your operational costs reasonable. Gone are they days when you need to over-provision resources in order to accommodate your heaviest loads. A reactive system is dynamic, able to adapt to real-time usage conditions, such as a spike of traffic from our users, to operational conditions, such as additional server nodes being added or removed from cloud infrastructure.

Using open source technologies such as Lagom and Akka, it is possible to build systems that tolerate failure of nodes, and can migrate state to surviving nodes and redistribute the workload in near real-time. This fault tolerance is highly valuable when deploying systems to cloud infrastructure and managing computing resources using Kubernetes. Compare this to complex session replication and failover mechanisms in heritage environments, and the advantages of reactive systems become compelling.

Developers working with cloud infrastructure are already creating distributed systems. CPUs have multiple cores, a server in a cluster has multiple CPUs, a cluster has multiple servers, and a data center will host many clusters of servers. Not only do we need to take full advantage of these resources, but we must learn techniques to leverage these resources in a highly distributed, highly concurrent environment.

The cloud gives us the means to create a virtually infinite pool of resources. Reactive systems development enables us to fully leverage those resources.

Prerequisite knowledge

This series is a hands-on, step-by-step journey to build the classical IBM Stock Trader system in a reactive style, with a focus on demonstrating code patterns common in reactive systems development.

We assume familiarity with domain-driven design (DDD) and event storming. Both of these techniques are fundamental to modeling and understanding reactive systems. There are a few resources that we highly recommend completing for readers without previous experience in domain-driven design and event storming:

  • Domain-driven design is covered in the "Reactive Architecture: Domain Driven Design" on Cognitive Class. This is a comprehensive but accessible introduction to DDD, which this series will build upon.
  • Event storming may not be familiar, so we will introduce it in this series. However, for a gentle introduction, this blog outlines event storming in under 10 minutes.

In addition to the above, optional learnings include the "Lightbend Reactive Architecture: Foundations" learning path on Cognitive Class, which provides part of the necessary background to follow along with the more technical details of these tutorials. As we move deeper into the implementation over the course of this series, readers may also want to complete "Lightbend Reactive Architecture: Advanced," which covers some of the specific techniques in later units, such as sharding, sagas, message brokers, and CQRS (Command Query Responsibility Segregation).


The following items make up this series (Units 5 – 12 to come):