24th of May, 2019
Reactive in practice: A complete guide to event-driven systems development in Java is a 12 part series that takes learners through the entire spectrum of a real-world event-sourced project from inception to deployment.
The entire series is supported with a reference project called Reactive Stock Trader.
I’ve been collaborating with IBM for months to bring this series to anyone interested in apply the event sourcing and CQRS patterns to real world enterprise systems. My background is mostly in banking and finance, so all of the event sourcing and CQRS examples are framed around IBMs classic Stock Trader. This series rethinks that classic application as a reactive system.
The stock trading domain lends some really interesting opportunities to explain asynchronous systems. For instance, the settlement of a trade is a long running process with multiple steps involved, which makes it a great flow to model in an asynchronous system. Most tutorials about event sourcing and CQRS shy away from these more complex aspects of enterprise development, but we’re jumping into them full stop!
Event sourcing is an approach to persistence that derives the current state of an entity from events, rather than storing the current state explicitly and reading back that value, for instance, by updating a row in a relational database using SQL. In other words, in event sourcing, we derive current values from past events rather than setting current values and throwing away the events.
This is a powerful pattern for building enterprise systems, because it preserves the ability for us to replay events to inspect how a system arrived in its current state. It’s not only important for us to know what something is, it’s also important for us to know how something became what it is. Event sourcing is the pattern that delivers both qualities.
A major beneficial property of event sourced systems is that events are one of the critical raw ingredients of machine learning. Adopting event sourcing in your core systems can help to fast track future machine learning initiatives. Your data science team will thank you!
CQRS (Command Query Responsibility Segregation) is a design pattern based around the separation of reads and writes. With CQRS we build unique data models for reads and writes, giving us the ability to treat them as separate concerns with separate requirements. This separation of concerns gives us the ability to optimize each side individually, which is mandatory in systems that deal with a high volume of transactions, queries, or both.
In this series you’ll learn how to pull computation out of the ‘real time query path’ using asynchronous data pumps. This can help reduce the latency of queries which involve complex joins from seconds to milliseconds.
Reactive in Practice is one of the most comprehensive free sources of training material on this emerging programming paradigm. Below are the topics covered in this series.
| Unit | Topic |
|---|---|
| Unit 1: Domain modelling | This first unit begins with the basics of domain modeling and how to think about the fundamentals of designing a reactive system. |
| Unit 2: UI integration patterns | A reactive system needs to be reactive all the way down from the UI to the database. We begin describing this style of development with the UI. |
| Unit 3: Designing a reactive API | Next we define the API and contract between our reactive services and the user interface, and special considerations for API design for reactive systems. |
| Unit 4: Concurrency patterns | We explore the first-principles of asynchronous programming by describing important concurrency and parallelism models, including threads, promises, futures, and actors. |
| Unit 5: Event sourcing | We cover the basics of real-world event sourcing using hands-on code developed with Lagom and Cassandra. Learn the basics of projecting current state from an event stream. |
| Unit 6: CQRS - Writes | Learn how CQRS (Command Query Responsibility Segregation) is applied to the ‘write side’ of a reactive system. This enables us to tune writes for performance and resilience separate from queries. |
| Unit 7: CQRS - Queries | Implement the ‘read side’ of CQRS to efficiently query an event sourced system by generating query tables asynchronously for near instant real-time queries. |
| Unit 8: CQRS - Transactions | Learn how to manage a long-running transaction flow with multiple steps in a CQRS-based system. This is one of the most complex topics in reactive programming. |
| Unit 9: Reactive integration patterns | Integrating a reactive system with legacy systems requires a diverse set of principles and practical implementation experience. We cover the basics of what you must know. |
| Unit 10: Streaming events | We begin to connect all components of our reactive system all the way up and all the way down, establishing a resilient end-to-end channel for bidirectional real-time streaming of events. |
| Unit 11: Deploying to Kubernetes | See how modern container management platforms, like Kubernetes, make it easier to deploy a reactive system to a production environment. We step through how to set up Minikube along with all necessary dependencies for local development. |
| Unit 12: Conclusion and summary | We present a broad overview of reactive systems development and summarize all of the topics above for principle developers and architects. |
Complete examples of this material are very sparse in the industry because they are so time intensive to create. With the support of IBM along with review assistance from Lightbend we’ve brought this material to life. We hope it inspires the community and showcases best practices of these exciting principles, practices, and technologies!