Thinking to use Event Sourcing???

A quick recap

Event sourcing is an architectural pattern that tracks changes to application state by storing a sequence of events, each describing a specific change. This approach allows systems to reconstruct the current state by replaying these events.

Workflow:

Producers → List of events → Apply Business Logic → Generate the Desired State

• Event sourcing is eventually consistent.
• It is good for creating materialized views.
• It is excellent for compliance that requires audit trails.

Challenges

• Super High Storage Costs: Event sourcing requires significantly higher storage (10–100x) and can become costly. Periodic snapshots can help mitigate this, but even then, be prepared for the costs of archive storage also.
• Expensive Computation: Each time a state is needed, the business logic must be executed on all events.
• Complex Queries for Analytics: Events are raw data, not actionable information. Business logic must act on all events to produce meaningful results.
• Schema Evolution: Event schemas evolve over time, so the business logic must support all schema versions.
• Handling Duplicate Events: Managing duplicate events is challenging. For example, if a producer writes to an event store and the network fails, it may be unclear if the event was acknowledged or not.
• Undo Operations: Supporting undo operations is very hard. Compensating events must be triggered manually or by scripts.

  For instance, consider a failed bank transaction where money is debited from the source account but not credited to the target account. A support team could fix this executing few queries on tables in a traditional RDBMS system. However, in event sourcing, support staff must dig through event logs, trigger compensating events, and execute business logic to verify the correct state.

  Now, imagine this complexity across various transaction types in a bank. This would significantly increase the complexity of support interfaces compared to simply updating database tables.