AxonIQ

Event Sourcing "Friday FUD": One challenge of Event Sourcing is that I can't change historical data. Or can I? The short story is simple: you can. But you might get in trouble, and it's not because of Event Sourcing. One of the things I love most about event sourcing is that it forces people (not only developers) to think in terms of messages—little nuggets of information that flow between components in a system. Some of these nuggets describe something from the past and hence are stored for longer. To make these information streams reliable, we use them directly to drive decisions in our system. The main point here is these nuggets of information that flow between components in a system. Whether we use Event Sourcing or not, once information is shared between systems, we should be extremely cautious when changing it. There is an assumption that because Event Stores are append-only storages, it's impossible to change their contents in other ways than appending more data. While that might be true for some specific implementations, it's not a general rule. At AxonIQ, the event store is part of Axon Server. We have a feature to transform the stream of events. 🤔 So I can change the data in historical events! That's great. Update queries for the win! Well, no. Coming back to the nuggets of information flowing between components, you shouldn't. If you change something in the past, the other systems won't be notified of this change. As a result, you have eventually reached a state of inconsistency. 🤔 If change is bad, why have a feature to change historic events? Not all changes are equal. As long as a change doesn't modify an event's semantics—its meaning—it is no problem to change it. We're only changing the representation of the same "nugget of information." These changes can happen for several reasons. Schemas may evolve, requiring you to change the representation of certain messages. Privacy regulation may also require removing information stored in your historical events. While there are different strategies to deal with these changes, altering the data should not be discarded as an option simply because event sourcing is advertised as append-only. But make sure to look at alternative solutions as well. Event Sourcing comes with many ways to address these issues. 🤔 But what if we need to change an event's semantic meaning? Don't. Changing that will change the story you've already shared with other systems or components. This is where Event Sourcing's strength comes in: fix forward. Make corrections by appending new events. These will then travel around your system like any others, fixing the "story" in downstream components as well. And yes, the fact that it happened will remain visible in the event store. So be it... Interestingly, the inability to change data is attributed to Event Sourcing, while it's actually Event Sourcing that provides better ways to deal with the situations that require it.

Event Sourcing "Friday FUD": One challenge of Event Sourcing is that I can't change historical data. Or can I? The short story is simple: you can. But you might get in trouble, and it's not because of Event Sourcing. One of the things I love most about event sourcing is that it forces people (not only developers) to think in terms of messages—little nuggets of information that flow between components in a system. Some of these nuggets describe something from the past and hence are stored for longer. To make these information streams reliable, we use them directly to drive decisions in our system. The main point here is these nuggets of information that flow between components in a system. Whether we use Event Sourcing or not, once information is shared between systems, we should be extremely cautious when changing it. There is an assumption that because Event Stores are append-only storages, it's impossible to change their contents in other ways than appending more data. While that might be true for some specific implementations, it's not a general rule. At AxonIQ, the event store is part of Axon Server. We have a feature to transform the stream of events. 🤔 So I can change the data in historical events! That's great. Update queries for the win! Well, no. Coming back to the nuggets of information flowing between components, you shouldn't. If you change something in the past, the other systems won't be notified of this change. As a result, you have eventually reached a state of inconsistency. 🤔 If change is bad, why have a feature to change historic events? Not all changes are equal. As long as a change doesn't modify an event's semantics—its meaning—it is no problem to change it. We're only changing the representation of the same "nugget of information." These changes can happen for several reasons. Schemas may evolve, requiring you to change the representation of certain messages. Privacy regulation may also require removing information stored in your historical events. While there are different strategies to deal with these changes, altering the data should not be discarded as an option simply because event sourcing is advertised as append-only. But make sure to look at alternative solutions as well. Event Sourcing comes with many ways to address these issues. 🤔 But what if we need to change an event's semantic meaning? Don't. Changing that will change the story you've already shared with other systems or components. This is where Event Sourcing's strength comes in: fix forward. Make corrections by appending new events. These will then travel around your system like any others, fixing the "story" in downstream components as well. And yes, the fact that it happened will remain visible in the event store. So be it... Interestingly, the inability to change data is attributed to Event Sourcing, while it's actually Event Sourcing that provides better ways to deal with the situations that require it.

Your system’s past holds the key to its future. Event sourcing can transform your architecture, fueling everything from auditable banking apps to machine learning pipelines. But let’s be real: adopting it can feel impossible. That’s where AxonIQ steps in, cutting through the noise and making event sourcing intuitive, scalable, and, dare we say, easy. Curious? We break it all down below. 👇 Have you tackled event sourcing in your projects? Share your story in the comments—what worked, what didn’t, and how do you see the future of event-driven systems? #EventSourcing #Microservices #SoftwareArchitecture

I am not head over heels for AI. Nonetheless, something quite interesting from that space was brought to my attention last week, and I would like your input on it. Axon Framework sees new issues and pull requests weekly. Nothing new there. What is exceptional, however, is that we got a pull request that added a single line. To the "Getting Started" section of the README of all things. To be more specific, the following was provided: You can Ask Axon Guru (https://lnkd.in/ebeRB5Fr), it is an Axon-focused AI to answer your questions. So, an "Axon Guru." An AI that is trained on the Axon Framework GitHub repository and AxonIQ's documentation, to be exact. As I told you, I am not a massive fan of the whole AI thing. There is nothing wrong with liking it; it is just not my thing. Or my thing yet, who knows? But I take any documentation or code provided to Axon Framework seriously, even if my first reaction is full of doubt. So, I checked out this Axon Guru to see what answers it came up with. To be entirely honest with you...the answers are pretty good! Here are some queries I tried: 1. Can I break apart my aggregate? 2. How do I use event sourcing? 3. What should my aggregate identifier look like? 4. Are there test fixtures for Event Handling Components? 5. Can I serialize my messages to protobuf? The only prompt in which I saw it make an error was the Event Handling Components testing. We don't have test fixtures for those. Other than that, the information was pretty impressive! I can honestly imagine there would be quite a few Axon users who would be very happy with a "guru" like this. Nonetheless, I would much appreciate your opinion on the matter: What do you think about AIs like this to help you learn an (open-source) tool or framework? Let me know! Before closing, I would like to thank Kursat A. for taking the effort to (1) set all this up and (2) nudging us with a PR that it exists. Kudos!

Software architecture isn’t just code—it’s about strategy and decisions. What skill do you think sets the best software architects apart? Explore resources for better system design with the all new AxonIQ docs page here: https://lnkd.in/gpVymT3F

🔔 Event Sourcing: Your Boost for NIS2, DORA & AI! Do you want data that stands out? 🌟 The EU is demanding more security, traceability, and transparency with NIS2 and DORA. But hey – why just meet the requirements when you can also make your data AI-ready? 👉 The Magic Formula: Event Sourcing. Unlike "old" systems that overwrite data, Event Sourcing stores every change as an Event. This brings: ✅ Maximum Traceability: Who changed what, and when? ✅ Perfect Compliance: NIS2 and DORA requirements? Check. ✅ AI-ready: Data that AI will love. 💡 Our Gamechanger: The Axon Framework! For over 8 years, we’ve relied on AxonIQ’s framework – because it just works and is fun to use. And this year, we were even sponsors at the AxonIQ Conference in Amsterdam. What did we bring back? Insider tips, best practices, and exciting success stories! 🚀 So, what are you waiting for? Event Sourcing is the key to starting the future securely, efficiently, and AI-ready. 📩 Let’s talk! Send us a message here or schedule a meeting directly. We’ll show you how Event Sourcing can transform your business. #EventSourcing #softwareengineering #Innovation

Lemon Companies Solutions architect Laura Devriendt calls it 'a real advantage.' AxonIQ Console is designed to make your life easier—try it today (free!) and let us know if we’ve nailed it: https://hubs.li/Q02-519m0

LAST CHANCE TO JOIN TODAY’S FREE WEBINAR — click the link below for details

What’s new at AxonIQ? Smarter tools, simpler setups, and faster performance. Read below to see some recent updates designed to make your life as a developer easier.