Time is running out! Call for Code submissions due July 29 ›
DAYS
HOURS
MINUTES
SECONDS
Series
by Kevin Webber, Dana Harrington | Updated May 24, 2019 - Published February 12, 2019
JavaReactive Systems
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.
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:
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.
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:
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 9 – 12 to come):
Define the building blocks of a reactive system, starting with event storming.
Prototype interfaces for Reactive Stock Trader.
Start development of a reactive microservice.
Understand the fundamentals of asynchronous programming principles.
Understand what the PortfolioEntity is and how to implement your own PersistentEntity in Lagom, leading into event sourcing.
Learn about a CQRS-based system, which allows separate models for reads and writes, enabling individual optimization for each side.
Learn how to query an event-sourced and CQRS-based system, and how to move processing into its own asynchronous boundary.
Explore how to manage a long-running transaction flow with multiple steps, processing wire transfer events as an example.
ChicagoJava+
Back to top