When to Event Source, and When Not To

Not everything belongs in an event store. Deciding what to capture is just as important as deciding what not to capture. Your team should event-source business decisions that need permanent audit trails, such as orders, payments, and state changes. However, you should not event-source high-frequency measurements like sensor readings, GPS pings, or log data—stream those to analytics platforms instead, or aggregate them into meaningful thresholds and translate them into business decisions before they touch your event store. The distinction prevents bloated event stores, performance problems, and runaway cloud costs.

What Is Event Sourcing and When Should You Use It?

Event sourcing is a pattern where you store every state change as an immutable event, then reconstruct the current state by replaying those events. Unlike traditional databases that store only current state, event sourcing keeps the complete history.

When to use event sourcing:

• You need complete audit trails for compliance (financial services, healthcare)

• You must reconstruct past states for disputes or analysis

• Business decisions need to be explained years later

• Regulatory requirements demand immutable history

When NOT to use event sourcing:

• You’re capturing high-frequency measurements (IoT sensors, GPS, logs)

• Current state is all that matters (shopping cart contents, user preferences)

• Events have no business meaning beyond analytics or notifications

• Your team lacks experience with event-driven architecture patterns

• Simple CRUD operations satisfy all requirements

The problem? Most teams don’t make this distinction clearly, leading to architectural decisions that create more problems than they solve.

Download the Event sourcing decision guide