Posted by In software, the only thing that is constant is change. And software architecture is no different, it has to evolve. Simply put, system components should be organized in such a way that they support constant change without any downtime, Even if all the components are changed or completely replaced, the show must go on.
“Software architecture has to be technology agnostic, Resilient, and designed for the incremental change.“
If we think about the Theseus paradox, Evolutionary architectures care less about the sameness of the ship(s) and focus more on whether the ship would keep on sailing. In short, architecture has to be technology agnostic, resilient and designed for the incremental change.
We can call any system “evolutionary” if it is designed for incremental change and can evolve with the changing nature of the business. Microservices style architecture is considered evolutionary because each service is decoupled from all other services in a system and communication between services is completely technology agnostic, therefore replacing one microservice with another is rather easy.
Microservices architecture focuses more on the technology-neutral communication between the components, loose coupling, versioning, automated deployment etc. but it doesn’t say anything about how each service or a complete system should store data internally.
Event sourcing (ES) pattern can serve as the missing piece in the puzzle, by defining data storage strategy.
Butchering the data is a criminal offense
In many businesses, modifying or changing the data is a crime, for example, Banking, forensic, medicine, law etc. Remember Accountants don’t use erasers. Whether we like it or not, for certain businesses like Telecom and ISP retaining data for a certain period of time is compulsory.
Can you imagine CCTV systems without recording? what will happen if something happens and you have no record of it?
“Most serial killers kill for enjoyment or financial gains.“
In the early 1990s, Dr. Mike Aamodt started to research about serial killers behaviors. It took him and his students decades to study and analyze public records before they could answer why and how serial killer kills? this wouldn’t have happened without historical records. In order to answer future questions, we must persist everything that is happening today.
Don’t create serial killers of the data.
We all know that the currency of the future is data. We don’t know what tools and methods we will have at our disposal in a decade, we certainly can’t predict how important that data could be for our businesses or for us personally, Still, we design and develop applications that are constantly murdering valuable data.
CQRS/ES
We as a species accumulate memories from our experiences, We simply can’t think like a CRUD system. There is a reason we love stories and pretty much everyone hates spoilers, Our brains work like an ES system.
Event sourcing is a way of persisting domain events (the changes that have occurred over time) in your application, that series of events determine the current state of the application. ES and CQRS go hand in hand, We simply can’t talk about ES without mentioning the CQRS (Command and query responsibility segregation). I generally explain CQRS with a notion of one-way and two-way streets or separate paths for pedestrians, cycling, and other traffic.
let’s see how Greg Young himself explains it.
CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation: a command is any method that mutates state and a query is any method that returns a value).
— Greg Young, CQRS, Task Based UIs, Event Sourcing agh!
The advantages of using CQRS/ES
- A complete log of changes
- Time-traveling (replaying events is like storytelling)
- Easy anomaly and fraud detection (by log comparison)
- Traceability
- Death of cannot reproduce or Easy debugging (production data can be debugged in the development environment)
- Read (with CQRS) and Write performance
- Scalability (with CQRS)
Common use-cases
Event sourcing enables you to audit state changes in your system. Auditors will love you for this. Historical records can be used to perform analysis, and identify interesting patterns. We must consider ES when accountability is critical (e.g Banking, medicine, law).
If your system by nature is Event-driven then using ES is a natural choice (e.g game score tracking, online gaming, stock monitoring, real-estate, vehicle tracking, social media like twitter, facebook, LinkedIn etc).
You should consider this pattern If you need to maintain versions or historical data for example document handling, Wikis etc.
Similarly, after each change, we can replay all the events and inspect the logs to see if the expected change is there? and does it work?
Conclusion
Most people think embracing ES is complex, however, I believe in the opposite. I think ES systems are easy to scale and change. All the mature industries like Banking, Finance, Law, and Medicine already use these methods, even before computers were invented.
We simply can’t destroy the data, because we can’t predict what tools will be available in a year from now, and how useful this data would be in the future.
In a forthcoming blog, we will show you a production-quality implementation of a system that has the potential to evolve.
If you happen to be in Stockholm and have an irresistible urge to discuss evolutionary architectures such as CQRS/ES lets have a “Fika”.