As a learner, many of us are confused between Event Driven Architecture and Event Sourcing. We have already discussed the former here and this article is especially for Event Sourcing.
What is Event Sourcing?
For the formal definition, we can say that event sourcing is a special arrangement to store data as events in an append-only log. However, it doesn’t limit there but keeps the context of the events as well. It lets you know if and why an invoice was sent from a single data piece. This means that the append-only store is a replacement for storing the current data in a domain. The store is a system of record that can be used to unfold the domain objects.
You can simplify the work in complex domains because, in event-sourcing, there is no need to synchronize the data model and the business model but still have a great improvement in performance, scalability, and responsiveness. To top it off, the system can have transactional data with consistency while the full audit trails are maintained, and the history is open for enabling compensating actions at any time.
What is different from Event-Driven Architecture?
The event-driven architecture uses events to maintain communication within the system where the sections are unaware of each other. Likewise, event sourcing uses the events as a state which is a different approach to storing data. To note, event sourcing is one of the patterns for implementing EDA in your system if your use case requires it.
Advantages of Event Sourcing
- Flexible — can store any kind of message
- Real-time data reporting is well accomplished in event sourcing
- Audit logs for high compliance systems can also be easily achieved
- Fail-safety is good — you can reconstruct data from the event store
Disadvantages of Event Sourcing
- Each event will have an individual payload
- Requires complex network infrastructure
- Need to have a separate way to control the message formats. E.g., Schema registry.
pragyaasapkota
/
System-Design-Concepts
Though the concepts of system design might be tricky, let's see them individually to their core concepts and have a better understanding.
System Design
Systems design is the process of defining elements of a system like modules, architecture, components and their interfaces and data for a system based on the specified requirements.
This is a index for the concepts of system.
If you wish to open these in a new tab, Press CTRL+click
| S.N. | Table of Content |
|---|---|
| 1. | Caching |
| 2. | Network Protocols |
| 3. | Storage: The Underrated Topic |
| 4. | Latency and Throughput |
| 5. | System Availability |
| 6. | Leader Election |
| 7. | Proxies |
| 8. | Load Balancing |
| 9. | Endpoint Protection |
| 10. | HTTPS: Is it better than HTTP? |
| 11. | Polling and Streaming |
| 12. | Long Polling |
| 13. | Hashing |
| 14. | CAP Theorem |
| 15. | PACELC Theorem |
| 16. | Messaging and Pub-Sub |
| 17. | Database |
| 18. | Logging, Monitoring, and Alerting |
| 19. | Distributed System |
| 20. | Scaling |
| 21. | Event Driven Architecture (EDA) |
| 22. | CQRS |
| 23. | Message Queue |
| 24. | Architectural Patterns |
| 25. | Enterprise Service Bus (ESB) |
| 26. | SLA, SLO, and SLI |
| 27. | Heartbeat |
I hope this article was helpful to you.
Please don’t forget to follow me!!!
Any kind of feedback or comment is welcome!!!
Thank you for your time and support!!!!
Keep Reading!! Keep Learning!!!
Top comments (0)