Do you really need “Event Sourcing”?
By: Prasad Jayakumar
Tags: Architecture, Java, Events, Domain Driven Design, Database

Event Sourcing involves two key aspects— Application State and Logs. At any given point-in-time, application state can be reconstructed from zero to up-to-date by replaying the events (logs). Event logs would be the source of truth.

Benefits associated with Event Sourcing are (please listen to Martin Fowler session for more details)

Audit Trail

Replay or Historic State

Debugging

Variant Schemes / CQRS

Distribution Support

Alternative Histories

Typical examples used for explaining Event Sourcing is Order. Let’s consider Shopping Cart for “events on the inside” and Sales Order for “events on the outside”

💡Order Management is actually more complicated than what most of the blogs or video sessions explain.

Shopping Cart (Events on the Inside)

Note: Delete event can be captured in many different ways. For simplicity sake, I have used negative values in quantity 😄 (definitely not a real use-case).

Event Sourcing may not be good for these kind of internal transactions (or events). CRUD (Transaction Script) approach would be adequate.

Alternate approaches to reap the benefits

Audit

Certain times, business requirements or regulatory requirements dictate the implementation. E.g, Bookkeeping and Bank transactions —

a. Don’t delete any transactions,

b. Put a reversal entry if required

c. Create a summary statement if required

d. Create snapshots as required like monthly closing or annual closing

a. Don’t delete any transactions, b. Put a reversal entry if required c. Create a summary statement if required d. Create snapshots as required like monthly closing or annual closing In all other cases, on-need basis, we can keep track of the transactions/events and purge after a threshold

Replay or Historic State

Apache Kafka kind of event streaming layer can keep track of transactions and allow to replay.

Traditional messaging layer can be used for replay, but it will be a stretch. Custom development would involve to persist all events and use event producer to regenerate the events.

Note: Constrained by available storage space and time taken to reprocess

Debugging

Use ELK stack or Splunk kind of log management tools for easy debugging. Plug the stack as one of the event consumer.

Variant Schemes / CQRS

Reporting databases approach is a low tech alternate, but served the purpose for longer period in the industry

Materialized views is a database feature which allows full refresh and “incremental” refresh

Change data capture and event stream can be used to build variant schemes

Distribution Support

Allow the database to handle these features instead of your application trying to address. E.g. Write and Read Replicas feature in most of the databases

“Alternative histories” use-cases could be a good-fit for Event Sourcing.

Use cases related to Business Events (Events on the outside) would actually go against Event Sourcing, whenever external systems are involved. In most of the real-world systems, external systems or other department systems would always be there.

Business Events

We cannot arbitrarily replay the events, unless we ensure the notifications and requests to external systems are disabled.