Data Modeling medium
How does 'Event Sourcing' differ from traditional state-based modeling?
- A Event Sourcing is a specialized pattern that requires the use of multiple high-speed write-replicas to maintain a persistent state across regions.
- B Event Sourcing strictly forbids the use of traditional relational databases, as the sequence of events can only be processed by a distributed log like Kafka.
- C Instead of storing the 'Latest State', it stores the sequence of immutable 'Events' that occurred; the current state is then derived by replaying these events.
- D Event Sourcing provides a significant increase in read throughput by eliminating the need for the database to perform complex join operations for current state.
Answer: C. Instead of storing the 'Latest State', it stores the sequence of immutable 'Events' that occurred; the current state is then derived by replaying these events.
Event Sourcing provides a high-fidelity audit trail and allows developer to 'rebuild' the system state at any point in history, making it invaluable for debugging and compliance. However, it introduces significant architectural complexity: querying the 'current state' can be slow if there are millions of events to replay, leading to the use of 'Snapshots' and Read-Model synchronization patterns.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- When modeling a Distributed Transaction using the Saga Pattern (Choreography or Orchestration), what type of consistency do you achieve?
- Which practice prevents SQL Injection attacks?
- What is 'Bi-Temporal' data modeling (e.g., in SQL:2011 standard)?
- Adding an Index to a database column generally improves Read performance. What is the negative trade-off?
- Log Systems Merge (LSM) Trees (used in RocksDB, Cassandra) optimize for fast writes. What is their primary downside regarding Disk I/O?
- What is the primary objective of normalizing a relational database schema (e.g., to 3NF)?