 The following is a Coderland presentation about our latest attraction, the Reaktica Roller Coaster. Hello, this is Doug Tidwell for Coderland. In this video, we'll go through the Reaktica architecture. We'll start by looking at the components that produce the data that drives the entire system, then we'll look at the components that consume that data and ultimately generate the web UI that is the whole point of this exercise. As we get going, we assume you've cloned or forked the Reaktica repo available at the URL on your screen. We'll discuss everything in terms of this diagram. There are five components. In the upper left, there's the component that generates user and ride objects. The new objects are sent as events to the AMQ broker. In the lower left, there's the event store component that takes data from AMQ and stores it in the data grid. In the lower right are the queue length estimate and current waiting line components. Those consume data from the data grid and generate the data consumed by the billboard UI component in the upper right. As we get started, let me say that we're not going to do a deep dive into the code here. The article that accompanies this video does that. And of course, you can always look at the code itself to see exactly how things are written. So let's look at the main data producers on the left side of the diagram. The users and rides components, as we said, generates user and ride objects. Those objects are the heart of the domain model that Reactica uses. They're passed as JSON data in an event object. For the objects themselves, a user has a name and a state. The state of a user goes from in queue to on-ride to completed ride. The user object also has data about when they got in line and when they got off the ride. A ride object represents a single round trip off the coaster. When a ride status changes to in progress, some number of users have their state changed to on-ride. When the ride status changes to completed, those users have their state changed to completed ride. The event store component makes sure that all of the user objects end up in the data grid. The users and rides and event store components on the left side of the diagram create the data that drives everything else in the system. Now we'll look at the right side of the diagram. The queue length estimate and current waiting line components are consumers of the data in the data grid. They also produce data that is consumed by the billboard UI component. It's important to remember that in a reactive system, a given component can be both a producer and a consumer. The queue length estimator uses a periodic query that runs every 10 seconds. It looks at the number of users in line, how long the ride takes, and the number of users who can ride at the same time. So if there are 20 people in line, the ride takes a minute and 10 people can ride at once. The 21st person in line will have to wait roughly 3 minutes. The next two rides that leave the station will carry the first 20 people in line, so the new person at the back of the line will have to wait for the third ride. If there were only 19 people in line, the new guests can get on the second ride, so their wait time is only 2 minutes. Which brings us to the continuous query used by the current waiting line component. A periodic query, as you would expect, queries the data grid periodically. A continuous query, if you're not familiar with the term, sounds like, well, something that queries the data grid continuously, but that's not how it works. The query runs once when we set it up, then the current waiting line component becomes an observer of the data in the data grid. When we run that first query, we ask for all the users that are currently in line or on the ride, along with no more than 10 users who have completed the ride. We show a few completed users, but there's no point in listing all of them. When we set up the query, we get the results of the query right away. The best thing about the continuous query is that whenever any data that matches the query is created, or any existing data that matches the query changes, the data grid sends the new data to the current waiting line component. Again, we're basically registering that component as an observer, the data grid tells us whatever we need to know. It's a great architecture for dealing with asynchronous data in a reactive system. The last component, and the one that ultimately does the work we set out to do, is the Billboard UI. It subscribes to two queues at the AMQ message broker. One queue is data sent by the current waiting line component, the other is sent by the queue length estimate. Anytime any new data about the current line or wait time is sent to AMQ, the billboard component receives that data and updates its display. We'll look at the web UI in the next video. So that's the architecture of Reactica. Remember our earlier definition? Reactive programming is programming with asynchronous data streams. The components of the system produce and consume data independently, but the system as a whole creates the web UI that shows the current state of all the data we care about. Thanks so much for watching and be sure to keep going with the next video. As always, let us hear from you if you have any questions, suggestions, or even PRs. We're coderland at redhat.com. For coderland, this is Doug Tidwell saying may all your bugs be shallow. Cheers.