AxonIQ

Weekly poll Wednesday! This time, we want to know: how are you debugging your event-driven systems? By the wayyy, it doesn't have to feel like detective work. We created AxonIQ Console so you can see exactly what happened, when, and why—no crying necessary. Try it: https://lnkd.in/gawjVbVF

👋 Hallo, Entwickler-Community! heise online recently featured Allard Buijze, discussing why event sourcing is not a niche solution but a powerful approach to building scalable, resilient systems. 🔹 Why event sourcing simplifies complexity 🔹 How it enhances consistency in microservices 🔹 The mindset shift it requires Read the full interview (in German) here: https://lnkd.in/gVXtAZDP Let’s talk—how is event sourcing shaping your architecture?

The worst thing to do when building a scalable system is to build it at scale, yet this is what happens most of the time. I was recently reminded that 10 years ago, I told Jamie Dobson that I didn't build systems at scale but rather systems that could scale when needed. It wasn't a big deal for me then, but the fact that it still resonates 10 years later must be a sign that the difference isn't always obvious to everyone. Something about BIG attracts us. BIG systems usually come with interesting engineering challenges, and we (or at least most of us) love a good engineering challenge. Unfortunately, good engineering challenges also destroy all ability to meet a deadline. They're like black holes. Once an engineer is caught in the gravitational pull of an engineering challenge, they're lost. When we're dealing with deadlines, small and simple are key. Keeping something elegantly simple is a great engineering feat. It's actually far more difficult than some of the "The Incredible Machine" constructs that I see people call software. Don't be fooled by the meaning of deadlines. They're not always time-bound. If you work for a startup, your deadline is most likely financial. You want to prove your product-market fit before the money runs out. In practical terms, this generally means that we should stop building microservices. Instead, build one simple, monolithic system that does exactly what you need it to do. You'll want to prove that you can scale the system to one user first. In my time as a software architect at a consultancy firm, I've seen many beautiful large-scale technical solutions, but the business concept didn't scale to its first customer—a great way to waste money. Monoliths aren't necessarily bad. When appropriately designed, you can remove components from the monolith, deploy them separately, and even scale them dynamically. You'll want to postpone this for as long as you can. After all, the more deployment units you have, the more complex the environment becomes. In 17 years of applying CQRS and Event Sourcing to projects, I've learned that explicit messaging (Commands, Events, and Queries) greatly enables the modularity required to scale monoliths to microservices. I've not seen other approaches (yet) bring capabilities that come even close. The diagram below is a mildly modified version of the diagram I use in most presentations. My general recommendation is the same. The ideal place for software is as far up as you can get it (as modular/scalable as possible) and as far left (monolithic) as you can get away with.

Most architectures are amnesiacs. They keep the latest state and forget how they got there. That’s fine—if you enjoy losing context, debugging blind, and reinventing the wheel every time something breaks. Or, you could use AxonIQ. Event sourcing means never losing the story behind your data. Every decision. Every change. Always available. And we make it easy. 🔗 Get your memory back: https://hubs.li/Q03bfJxy0

We're thrilled to be featured in TechtopiaFYI, where CTO Allard Buijze shares his journey from coding on a Commodore 64 to founding AxonIQ. Discover how we're simplifying software development with event-driven architecture, CQRS, and Event Sourcing. Read the full interview to see how we're helping organizations adapt swiftly without accumulating technical debt: https://hubs.li/Q039ScJm0

🚨 Drop everything 🚨 Adam Dymitruk and CTO Allard Buijze are breaking down Dynamic Consistency Boundaries (DCB) live. Tune in below!

Don’t settle for ‘good enough.’ Learn how durable execution with Axon and Restate can make your CQRS and event sourcing workflows bulletproof. Join this webinar with Marc Klefter & Giselle van Dongen to get the breakdown you need to level up your architecture.

Really looking forward to discussing various #EventSourcing and #EventModeling topics with Adam. Join us live at 8PM CET, 2PM EST, 11AM PST

☕ THIS THURSDAY: Event Sourcing without the guesswork Coffee’s brewing, and so are the insights. Join us for a no-BS chat on where to start with event sourcing, event modeling, and more. 📅 March 6 | 16:30 CET / 10:30 AM EST 🎙️ Sara Torrey & Marc Klefter RSVP BELOW:

We are currently working to provide a means to inject 𝘀𝗲𝘃𝗲𝗿𝗮𝗹 𝗺𝗼𝗱𝗲𝗹𝘀 into a message handler. We call  this the "stateful message handler." This feature will give a couple of benefits, namely: 1. It simplifies tasks that act on several models. Note that models can be event-sourced, of course. Furthermore, with the Dynamic Consistency Boundary functionality, each event can have several tags. Supporting the DCB API makes it straightforward to load several models in one go. From there, the stateful handler would allow you to keep the models separate or combine them in a task-specific 𝘀𝗹𝗶𝗰𝗲. 2. Stateful message handlers can replace sagas. A saga is nothing more than a process acting on several associated event streams. By representing those streams as models for the stateful handler, each handler of a saga could be constructed in this fashion. 3. You no longer need to use framework specifics in your model. Especially considering DDD, placing framework details in your model is a massive no-no. You can keep the module 'pure' by injecting models in a stateful message handler. Thus, the command handling and event publication tasks are the concerns of the stateful handler instead of the model. Currently, we are working towards our first milestone for AF5. This milestone will include the 𝘀𝘁𝗮𝘁𝗲𝗳𝘂𝗹 𝗰𝗼𝗺𝗺𝗮𝗻𝗱 𝗵𝗮𝗻𝗱𝗹𝗲𝗿, with both a fluent API and annotation-based API to build them. It excites me tremendously to build this different style for Axon users. It has forced us to rethink many of our interfaces to give the needed flexibility. It has forced us to break open our annotation solution, making it use the fluent builder API of these components. And in doing so, it shows us all these new capabilities we can start building for everybody. Working on all this with Mateusz Nowak, Mitchell Herrijgers, and (of course, (from time to time 😉)) Allard Buijze for the last months is nothing short of awesome in my book. Hence, I am confident I speak for all of them when I say we are keen to have you play around with this 𝗮𝘀 𝘀𝗼𝗼𝗻 𝗮𝘀 𝗽𝗼𝘀𝘀𝗶𝗯𝗹𝗲.