Good morning, everyone. So for, I'm a speaker, I speak at conferences a lot, and I've been talking about event-driven systems for some years now, because I really think they're very, very interesting. And I've been building systems using it as a developer advocate, so I've got like, decades of experience as a backend, like Java developer backend systems. So now I get to build systems for fun and demos and things like that. But I've been fascinated with event-driven, and over the last year, I've been using something else, and the hint is, it's called this, Calix, but that's kind of changed my perspective on how to do software, and especially how to do event-driven software. So I think event-driven software is very, very interesting. And, but this approach that I'm gonna kind of show you as well, I think is interesting also. So maybe you'll think I'm crazy, some of my colleagues think I'm crazy because I'm talking about this neural processing with event-driven, but we'll see, you'll be the judge. So what I'm gonna do is, I'll do review of event-driven because I think a lot of people have heard about it if you're a backend developer or even full stack developer. But many people haven't used it. And they're gonna show you a bit of code, don't have a lot of time, but I want to show you a little bit of code and a different style of code as well.  I've been playing with a name, Neurosynaptic Services and Micromind, those types of things. But it's an interesting processing pattern. So with event-driven, one of the things I've been working on is a demo that's been a lot of fun for me. And it's called Ership. And the reason it's called Ership is that the user interface that I built is a map. You know, it's like a Google map, so you can go anywhere on the earth and you can zoom in onto a location on the map and then you can pick a circular region like you can see the circular regions here. And then you can say, I wanna create a simulated number of orders. You know, so this is like an e-commerce system. This is like, you know, the shopping cart demo was kind of like the hello world for backend applications. So I started with this simple shopping cart app, but that got boring really, really fast. So I wanted to make this more interesting and I wanted to do more interesting things with the demo app, but I always like to do this visual stuff so that you can, and this is on GitHub, I got QR codes where you can go grab the repo. But the idea is you zoom into a location on map, anywhere on the map you want, you could be in the middle of the ocean or it could be over a city or wherever you wanna do it. And then you can specify how many orders do you wanna create?  But what I wanted to do is kind of have this demo put a hurt on the backend system, already put a load on this system. And another thing you can say is a rate, like orders per second type of a rate. Then one click goes into this demo app and it starts generating a bunch of orders. So all these dots represent orders that were randomly distributed within the circular region. So this is a design diagram of this application. I'm not gonna be able to go into a lot of detail with it, but I want it, it is event-driven. So these rectangular boxes represent basically event-driven microservices, but they're of a very specific type. They're probably not like maybe what you've seen with other event-driven before because they're very focused on what they do. But what I wanted to do was show kind of visually what happens. So you can see in the bottom left, there's a client, I'm kind of highlighting a client, and it's sending in a command to a shopping cart service and it's adding, say, items to a shopping cart. So it's loading up a shopping cart. But the interesting thing is when the command comes in from the client to say checkout. So the service is emitting an event, checkout. Now, this is where things get interesting. That event is of interest downstream to another service, which is to create an order. So that triggers the creation of an order. So this is an event-driven flow that there's kind of a cascading sequence of events. Like I say, this got boring really really fast. So I wanted to plug in this UI. So the map in the top center there is sending in a single HTTP request to say, you know, I create 500 orders at this geographic location within this circular region. So that goes into another service, which starts triggering the creation of these orders. But you can see there's a flow like this generator got the initial request. It starts emitting events over and over to create these, what I call geo orders. And these geo orders are just orders at a specific geographic location. But here you can see the event coming out of geo order is of interest to a couple other services. And the point I want to make here is that each of these services, one of the things we've been talking about with microservices forever is they're supposed to be loosely coupled. And these are loosely coupled services. These services have an API, but they don't know who gave it send them commands. These services also emit events, but they don't know who or what consumes those events. They don't care. So every single service is only concerned with its own functionings, not concerned with the rest of the system. So this geo order service emits an event which happens to be of interest because of the wiring of the system to a couple of other services. But now we go deeper into the processing flow here and I'm not gonna go through what's happening here, but other than what this system does is allocate stock to the order. So it's doing something a little bit more interesting than just taking orders in. But you can see there's this kind of cascading flow of events that are coming in. I'll get rid of this thing here on what it is. That, you know, where the processing is occurring. So all these highlights are these cascading flows where commands come into one service. It emits an event. That event gets picked up by another one. So the logic of this system is built in, it's kind of decomposed down into these individual very focused little services that are wired together to orchestrate the whole processing of the system where it takes orders in, allocates stock to them and reports back to what the processing is. So this is the general flow of the system. This is a really different way to design a system. If you, you know, I, like I said, I've built back in systems for decades and, you know, with regular databases and crud-like operations, you know, multi-table transactions and all those types of things, this is not that type of behavior. So the design of this application was really interesting where I, you know, I decompose a problem down into each of these services is solving a different part of the problem. And it has this processing flow. And including things like allocating stock to the order. So that's kind of what this demo does. It's a fun demo to run visually on the map when the orders are first shown, they're grayed out, indicating, okay, the order's there, but we haven't processed it yet. And then just over a period of a few seconds when it runs, the orders will turn blue when they're allocated stock or they'll turn red when there's insufficient stock so the order's going to a backorder state. But that triggers other behavior that's in this design which will order more stock and as that stock comes into the system, that stock goes looking for back orders and fulfills those back orders so that all the orders get processed. Now, the other interesting thing is that the, there's three fundamental components that are used to build this system in this platform. There's the rectangular services, they're called entities. And like I say, they have an API. It's a simple API, I'll show you the code in just a minute. They have logic, basically, the service composes the state of a thing. It's like this shipping order item, for example, that's in the middle of this diagram. It's just a durable object, basically, that this thing is processing. And then it's submitting events. Now, as events driven, the events are for changing the state, like with a shopping cart, you add an item to the cart. Well, that's the command coming in. If the cart's not checked out, you run the business logic, if the cart's not checked out and it's a real product and everything looks good, then the item gets added to the cart, which means you're altering the state of the shopping cart by emitting an event. So the processing is, a command comes in, it creates an event, the event gets persisted and once it's safely persisted, then the event is used to alter the state of the object and that's the processing flow. So the big difference here is that these services are really simple, they don't reach out, they don't talk to databases directly. The state is recovered from the event journal. So like, what is the current state of a shopping cart? Well, it's got, add item three times, change an item quantity, remove an item quantity, checkout. The aggregate of all those events is the current state of the shopping cart. This is the basic behavior of these services. So let me show you a little bit of code. Here's the shopping cart service, it's in Java. Anybody Java, Spring developers here? Some? So some of this should look familiar. The API is definitely using Spring-like annotations, but you can see that on this line here, number 26, I just, I have a class and it extends a base class, it's called an event source entity, this is part of the software development kit here, this K-like software development kit. But then here you can see, here's how you define part of the API, like add an item to the cart. But the main thing I want to show you here because there's a lot happening right on this line 49, you can see there's above, it's like effects dot emit event. So what that is, that's the code that emits a new event that needs to be persisted by the underlying system. So this is a high abstraction, I just gave a talk earlier this week at another conference about high abstraction platforms, and Kalix is one of them, but I talked about four different ones. These are higher abstraction platforms that are abstracting away as much detail as possible. So this code does not connect to a database directly, it's connected to a database indirectly through the layer, the platform layer, that's below it. So the goal is the simplified development. So here it's like, admit an event. I don't know where it goes, I don't know what the database is, I don't care, that's the problem of the platform. My problem is worrying about the business logic and the service. So it emits an event. The next interesting thing is this current state. The current state is an inherited method from the base class, which composes, has the state of this thing, like in this case a shopping cart, as it is right now, retrieved from the database. This is also a stateful service, meaning that the state will be cached, kind of a very elegant caching mechanism where if the shopping cart's active and there's a user adding things to the cart, that cart's in memory somewhere in a cluster. There's one instance of it in memory somewhere in a cluster. And instead of having to retrieve the state every single time you're gonna make a change, it has it in there. But all that's being managed by the platform as well. You access in our code the state from this current state. And then this event for is a method I wrote. It's just my style, but it's really simple. It's just taking the command in and creating the event back and returning that. So these APIs, you can see the API, like add an item, change an item, remove an item, check out. This is all I'm doing. And then the next thing here is these event handlers. So the event handlers are invoked once the event has been safely persisted to the database and we wanna now make the state change. So if you look at this method, you can see that it's returning the state. So that's the state of the shopping cart. Altered by the event. So like with the add item, I'll take, go into this on method. You can see this is just basic Java. All I'm, you know, the object here has a list of items in the shopping cart. So all I'm doing is streaming through the list and adding the new item to the shopping cart. Very simple, no database, nothing like that. So there's all these event handlers for the different events. And then the state itself is just a Java record. And I really love Java records. It's one of the best inventions come out on Java because they're immutable. So that means that I can't write code where I'm gonna screw up and change the state when I shouldn't have or something like that. So it's really quite nice. But the, I have these event, just kind of overloaded event four methods for all my different commands. And then I have the on methods, overloaded on methods for all the different events. And that's the basic flow of this class. So no database connections, no worrying about publishing messages, things like that, but you can see that there's messaging happening in the system because the event from a shopping cart, like a checkout, is being picked up and processed by downstream services. So the other component that I wanted to show you is the shopping cart to order. And here I just want to show you really quickly so I can move on. The, this is called an action. And actions process the messages from upstream events. So the event comes into the action and the action translates, say a checkout into a create order command. And it sends that create order command to the downstream service, the order service to create an order from the shopping cart. So the logic in here is really simple. I'm not involved in pulling or anything like that or talking to Kafka or whatever, high abstraction type of code to do that. So that's kind of the code. So I want to get into the, the MicroMind piece here.  And when I was working on this design diagram and my goal for that design diagram where I showing kind of the cascading sequences of events but to help people visualize, you know, a flow and kind of a real event driven type of a system. And I thought they worked out pretty well but it took a lot of work. If you guys ever heard of Blender, Blender.org is a fantastic 3D tool and I love Blender and I'm going to show you something else that I've done in Blender in just a minute that I love. But so this diagram I did in Blender but it was a lot of work to do all this animation of highlighting each step of the processing flow. But you know, it's like when I was looking at it, it's like, okay, wait a minute. The way these services are working and the way there's this kind of cascading sequence of events that's occurring between the services, I started to think, wait a minute, this is somewhat like the behavior of, you know, the neurons in biological brains.   But the neuron itself doesn't know who sent it a signal. It knows it's received a signal. The neuron decides should it admit a signal. So it decides it admits a signal. It doesn't know or care who is wired up to receive that signal. All the neuron knows is basic mechanics. That's kind of what these services are doing here. Really simple, really focused, not complicated, not doing database transactions, kind of a pure, kind of an event driven type of thing where signals come in and signals go out and there's some logic in the middle to decide when, you know, how to respond to incoming signals and how to emit outgoing signals. So that kind of blew my mind because, you know, like I said, the shipping order, it gets a command in, does a state chain, emits an event. That event gets picked up by an action because the subscribe to it, that action takes that event and translates it into a command and sends it down to another service. There's your flow. So it kind of blew me away. So again, just kind of walking through it really quick. You can see this cascading sequence of events. You know, step by step, this is the exact flow of the way this application works. And what it's doing, it's not just taking in orders. Like I said, it's allocating stock. And what the system is doing with just these 13 simple services, it remembers exactly where every physical unit of stock went to every single order, all that is being handled. It's also handling back orders. Like when there's insufficient stock in the system and when stock comes into the system, it has logic to add stock to the back order orders, find them and allocate stock to them. All this behavior is in relatively simple service. So that's what's kind of cool here. Again, my colleagues think I'm not talking about this whole neural thing, whatever, but I don't know, I'm pretty psyched about it. The other thing that I thought was really interesting was that there were behaviors that were starting to emerge, recurring behaviors that I hadn't seen before in other code. So for example, there's like five or six recurring behaviors. I'll give you a summary at the end. But of the 13 services here, three of them kind of use the same kind of a hierarchical tree pattern.  And once I figured out how to use a reduction tree in this kind of a processing, and this isn't unique to Calix, I think is unique to the style of doing event-driven, that these patterns started to emerge. There's all these different reusable patterns that are starting to emerge here. And that intrigued me even more that maybe there's something really interesting happening here because I'm starting to think that the way our brains, biological neural networks are put together is the same type of thing. There's these recurring patterns in the way that all the things are wired together that are being used to do very, very powerful things. So it's this whole idea of services behaving more like neurons in other functions and behaving like synapses. By the way, this is all serverless as well on this platform. So these things are running in a cluster. They're getting allocated when needed. It scales up, it scales down, those types of things. So what I wanna show you is another visualization of processing the services. So what I did was, before I play it, cause I got time, I wrote specific log statements in the application so that I could scrape those log, specific log statements out of the log and use that as raw data to render the activity within the ERSHIP demo as it was processing orders. So what happens here is that that's one shopping cart getting processed and a stock getting allocated in the system. And then the two other shopping carts come in. But the fun part starts here, like there it goes. Now 200 orders are coming in from the map. And what's happening here, every dot represents an instance of one of the services getting created and the colors represent state changes that are occurring. So red indicates back orders. And yellow indicates things that haven't been processed yet. So it's processing and green indicates that, yeah, the stock's been allocated to the order and it's flowing back up. So you can see it's actually recognizing that the system's out of stock that triggers stock getting ordered coming into the system and getting processed. And you can see things turned from yellow to red to green and everything gets processed. And the lines that we're flashing represents the specific messages, like event came from a specific entity to another specific entity. So these lines aren't arbitrary, this is real data from the running of the application. And it's 3D, so this is the beauty of Blender. I wrote this code, by the way, it's Python. Blender has a massive Python API, but wanting to do this for years, I've been using Blender for a long time. But I used chatGbt to help me write the Python code to do this. So this was a blast, I was so happy when this video worked because what I think is really interesting here is I don't know if you watch videos on say the processing of neural networks or the processing, some videos are on YouTube, say like of insect brains or human brain activity and all those types of things, really awesome-looking videos. And I wanted to have a video like this, but for a software system. So this is about 10,000 entities were created, about 15,000 events happened as processing all these 200 orders. And then I already know some optimizations that I can do to this to cut things down some more. The other thing is that this system is, it's built to run in a fully distributed environment. Scale up, scale down, any part of this application can break and when it comes back up, the system picks up where it left off. It will not, it will keep running until it's finished its processing. Unlike AI systems like large language models, which have you heard about it, it'll lie to you with confidence or that they hallucinate like chat GPT and everything. I've seen it do it, you know, you ask it a question and it says, oh yeah, here's the answer. You look at it and go, no, that's not the answer.  This system is not trained, it's hard wired. Is it like it's got instinctive behavior, not trained behavior. So it's enterprise precise. We're using these patterns to do things like financial processing. And with financial processing, it's like you don't go back to your management and to your business sponsors and say, oh it works most of the time. Every once in a while we'll screw something up a little bit, no, no, that doesn't fly, right? So this is absolutely precise type of processing. And for example, decrementing stock. This knows exactly what's happening with stock. It won't make a mistake with stock. It won't make a mistake, say, aggregating financial transactions into merchant payments. That's another system that we worked on recently. Those types of things. So it's fully distributed, fully scalable, fully resilient, and absolutely accurate. And the nice thing is, is that I write this code and I'm really kind of focused on the pattern of the code. Not worried about resiliency, not worried about scale, not those types of things. Yeah, I mean of course when you're doing IOs, you're always thinking about can I, in my code, can I reduce the number of IOs that my code is doing? Those types of things. But it's a whole different way of thinking about building applications. So to kind of wrap up, what I like about this approach is that the microservices behave more like neurons. I've been talking about microservices since pretty much since they came out. And some of the things we've been talking about, talking about, but not necessarily doing, is things like microservices should do one thing and do it well. In this case, you're kind of forced to do it that way. And the behavior of the microservices, commands come in, commands emit events, events get persisted, and then the events trigger state changes. That's the flow. Those actions, those synaptic type actions, they're just consuming events. From upstream event producers, and for the most part, they're translating those events into downstream commands. They can do other things. They can do queries against views and things like that. Like for example, when I'm allocating stock to the order, the action has to do a query to see if there's any available stock to be allocated and it grabs that stock from the query. The messaging in the system, it's, I don't know or care how it's implemented. Well, I do know, but I don't care because I work for the company that built it and I talk to the engineers that built the platform all the time, but that's not my concern as a developer. As a developer, I'm focused on wiring together the flows, defining the flows, designing the flows and in my software at a very high level of abstraction. But the messaging is at least once, but that also means that you have to consider right in potency. And meaning that with at least once messaging, what that means is the consumer of the message will get a message at least once and it might get that same message twice. So if you're doing things like decrementing the balance of an account or taking inventory out of a stock or something like that, you have to think about that. How are you going to handle the processing logic when those types of things happen? So I mentioned the patterns and in the Earthship, relatively simple demo, there's two, it's called choreographed sagas. The choreographed sagas is the saga pattern without a controller so that the saga happens just because of the way things are wired together. There's a lot of these actions that do one to many, meaning that one event comes into the action but it emits multiple commands to multiple downstream services. That's a very common pattern. There's generation loops and generation trees. This reduction tree I mentioned earlier, there's three of them in the demo and the reduction tree is really for that, is reducing something like, how many back orders do I have for a particular product? How many, with the stock orders they're in, how much inventory do I have for a particular product? The reduction of all that detailed data is being handled by these reduction trees and they're really there for fried on potency. So like I said, this is a different way of thinking about doing event-driven. Maybe you don't have a platform that does it but so that's okay because I think event-driven itself is right there. So we did a review, looked at some of the event-driven architecture, looked at a bit of code and when it says MicroMind, I'll leave you with two things. This quote from Alvin Toffler, the literate of the 21st century will not be those who cannot read and write but those who cannot learn, unlearn and relearn. I had to unlearn a ton of stuff to and relearn new ways of doing things to use this new tool set. It was hard. I think we've discovered some patterns that will help people that follow us later on but this is a skill set that I think every one of us needs to have if we're in IT and this one's relatively new. AI will not replace you, people using AI will. I use AI like all the time. Most of the images that are in my presentation are AI created. I've been using co-pilot for a year. Get a co-pilot in my IDE for a year. It's amazing, it's like I'm sitting here, everyone's like, well I'm working at home and I come out to my wife and it's like this thing's in my head, it just reads my mind. It's just dumping out blocks of code and I'm just moving, it's amazing. So thank you very much, this is the QR code for the slide deck and I think we have a few minutes for some Q&A if you guys have any questions. Yes sir, that's a really good question. The only reason that particular service, the shopping cart service had that validation checks in it was because there was a client, an external client talking to it. The other services, and I think what you're getting at is when you're cascading, wiring services together, a service just can't reject, right? So this is very insightful, excellent question. The service has to have like a compensating action. So instead of just saying no, I can't process this message, it'll emit an event saying no, I didn't process this message and that event goes back, is wired to go back to say the event producer. That's a very common pattern that was in this type of a system, but so you have to be very careful about just rejecting incoming commands and it's only really for services that are on the edge of the system where there's external clients that aren't a venture of inclinants and can handle the error response. Any error questions? No, it doesn't, not in this system. It's not yet at least. So you mean like training it with, yeah. So that's an important distinction that the service, the behavior that's in this system, I kind of refer to it as instinctual. When we're born and when other organisms are born with a neural network brain, there's a certain amount of pre-wired behavior in the system that doesn't need to be learned and that's kind of analogous to what this system's doing. It's just pre-wired behavior. But what's interesting about this, I think, is that how powerful that pre-wired behavior can be. Like don't put your hand into a fire because when you feel pain, you immediately react. A lot of that is instinctual behavior. It's not learned behavior. Some of it is, but it's like insects, for example. They have some learning ability, but they have a ton of pre-wired behavior built into them. And that's kind of what this is. But it's extremely powerful. That's what's kind of surprising me. It's like, man, I'm doing all this stuff. With just these 13 simple services, the code's not complicated. It's the wiring together that makes this the behavior of the system really interesting. Yes, sir. There's a state of each instance. Like there's a state of a shopping cart, state of an order, state of stock, state of product, those types of things. And you have to think about that as you're designing the system. That's the fun part, the part I really enjoy doing this, is thinking through the design, thinking through the compensating actions. You kind of have a happy path where everything works just fine. That's kind of the easy path, but then there's the unhappy path. So things like there's services that, like an order comes in and the order's decomposed down into as individual physical units of stock that it needs and those physical units of order stock that need. They go looking for individual units of stock in the inventory. And it'll send in a request to one that's supposed to be available and that one's not available. So it emits an event that says, sorry, I can't join with you because I'm unavailable, some other order got me. So that event goes back to the requester, which triggers it to just try and get something else. But maybe there's nowhere stock the next time it goes back. So you have to think through that. So what happens when there's no stock? And so every single step you have to think through. It's not as bad as I feared it might be, especially when you're decomposing a problem into these small processing units. That's where I think it makes it simple. If you have a big bulky services getting kind of, it's got that smell because it's getting too big, then you know you're on the wrong track. And often the solution when I ran into that was to decompose it down into smaller delegate to smaller services. But you have to think about, make sure. I think we're out of time. So thank you very much for attending the talk.