Event sourcing is a way to store data as events in an append-only log. It only keeps the latest version of the entity state. This method stores the state of a database object as a sequence of events. It is essentially a new event each time the object changed state, from the beginning of the object’s existence. An event can be anything that is generated by a user, a mouse click, a key press on a keyboard, and so on. It is a great way to atomically update the state and publish events. Not just can we query these events, but we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes.
Events are immutable, they cannot be changed. This well-known rule of event stores is often the first defining characteristic of event stores and event sourcing.
EventsStoreDB
Events are persisted in an event store. Every change that occurs in the domain is recorded in the database. The event store is the database category that basically focuses on store events. The event store not only acts as a database of events, it also behaves like a message broker. It provides an API that enables services to subscribe to events. Each event that is persisted in the event store will be delivered to all interested subscribers by the event store.
An event store is a different type of database than a traditional database (graph, document, relational, etc.) It is specifically designed to store the history of changes, with the state represented by an append-only log of events.
The event store is the backbone of the event-driven microservices architecture.
Event Driven Architecture
Event-Driven Architecture is also commonly referred to as publish-subscribe model.
It usually have three components-
- Producer
- Broker
- Consumer
Basically, a producer creates the events that are going to be redirected by a Broker into the right consumers. Consumers will react to this event and execute the things that they need to execute.
When to use Event-Driven Architecture
There are many cases to use this architecture-
We use this architecture when scalability is more important than performance. Also when you want to have data replication. Basically, you need the same information in multiple systems, so instead of calling different systems to pass the information or having all these services call the same database, you can use events. So these systems copy the same information from the same source.
And also when you have parallel processing. If you have multiple services that you need to execute at the same time.
When decoupling is very important, and you have may be different heterogeneous systems, and you want to have all of them decoupled.
Benefits of Event Sourcing
- An event-sourced system stores data as a series of immutable events over time. It provides one of the strongest audit log options available.
- All state changes are kept, which allows to move systems backward and forwards in time which is extremely valuable for debugging.
- Business events can be linked to their parent event, providing traceability and visibility of the entire workflow from start to finish.
- EventStoreDB is a distributed database technology that support fault tolerance. If an event processing node fails, the second one will come to life immediately and the first node will be removed.
- In CQRS/Event-sourced systems the data flows through a one way independent model to update or read the information.
To explore more about Event Sourcing visit the links given below
- https://www.eventstore.com/event-sourcing
- https://martinfowler.com/eaaDev/EventSourcing.html
- https://eventuate.io/whyeventsourcing.html
