Event Sourcing is Not For Everyone¶

A few days ago, Martin Dilger published an article on LinkedIn titled "When Event Sourcing Doesn't Make Sense (And How to Know the Difference)". It's a thoughtful piece that addresses an important question: when should you not use Event Sourcing? The article sparked several private conversations, and one in particular revealed a confusion I see far too often.

Someone described a ride-sharing application where a driver continuously transmits GPS coordinates while traveling to pick up a passenger. The question was: are these GPS updates events? And if so, should they be stored using Event Sourcing? The answer reveals a fundamental distinction that many teams overlook: not everything that looks like data is an event, and not every event belongs in an event-sourced system.

The GPS Coordinates Problem¶

Let's dig into that ride-sharing scenario in detail, because it perfectly illustrates the confusion.

A driver accepts a ride request. They're currently 5 kilometers away from the passenger. They start driving. Their phone's GPS transmits their position every second. Over the course of a 10-minute drive, that's 600 GPS coordinates streaming into the system: latitude, longitude, altitude, speed, bearing, accuracy. Six hundred data points.

Now here's the question that trips people up: Are those 600 GPS coordinates events?

The instinctive answer for many developers is "yes." After all, they're things that happened. The driver was at position A, then at position B, then at position C. They have timestamps. They're being transmitted to a backend system. They fit the mental model of "events flowing through a system." So naturally, people think: Event Sourcing.

This is wrong. Those GPS coordinates are not events. They're raw data. Sensor readings. Measurements. They have no inherent business meaning on their own. A latitude/longitude pair at 08:25:17 doesn't tell you anything about what's actually happening in your ride-sharing business. It's just a data point. And if you try to treat 600 GPS coordinates per ride as events in your event-sourced system, you're going to build something that's expensive, slow, and fundamentally misaligned with what Event Sourcing is for.

Now let's look at what actually matters to the business. When the driver gets within 500 meters of the pickup location, the passenger needs to be notified: "Your driver is approaching. They'll arrive in approximately 3 minutes." That notification trigger is a business event. When the car stops at the agreed meeting point and remains stationary for more than 10 seconds, the system needs to know: did the passenger get in the car? That state transition is a business event. When the car starts moving again, the system must determine: did they start the ride together, or did the passenger fail to show up, or did the driver cancel? That decision point is a business event.

Here's what the actual domain events look like:

DriverApproachingPickupLocation
  subject: /rides/42
  data:
    rideId: 42
    driverId: 123
    estimatedArrivalMinutes: 3
    currentDistance: 450

DriverArrivedAtPickupLocation
  subject: /rides/42
  data:
    rideId: 42
    driverId: 123
    arrivedAt: 2025-02-17T08:25:17Z

PassengerBoarded
  subject: /rides/42
  data:
    rideId: 42
    passengerId: 456
    boardedAt: 2025-02-17T08:25:49Z

RideStarted
  subject: /rides/42
  data:
    rideId: 42
    startedAt: 2025-02-17T08:25:54Z
    startLocation: { lat: 52.520008, lon: 13.404954 }

Notice the difference? These events have business meaning. They represent state transitions that other parts of the system care about. The billing service cares when RideStarted happens because that's when the fare calculation begins. The insurance service cares because that's when dynamic coverage kicks in. The notification service cares because that's when it stops sending "where is my driver?" updates to the passenger. The analytics service cares because it's tracking pickup success rates.

These are the events you store in your event-sourced system. Not the 600 GPS coordinates. Those were just the raw input data that allowed you to detect these meaningful business occurrences.

Raw Data Becomes Events Through Context¶

The core insight from that discussion was this: raw data becomes event data only through business context.

I see this pattern everywhere. A few years ago, I worked with a manufacturing client who was building an Industry 4.0 system. They had temperature sensors on their production equipment that measured and transmitted readings every 100 milliseconds. Ten measurements per second. 36,000 measurements per hour. Over 850,000 measurements per day per machine. They had dozens of machines.

The question they asked me was familiar: "We're building an event-driven system. Should we use Event Sourcing for all these temperature readings?"

No. Those temperature readings are raw data, not events. A temperature of 72.3°C at 09:14:23.847 isn't a business event. It's a measurement. It has no inherent meaning on its own. The machinery is just running. Nothing special is happening.

But then certain things occur that do have business meaning:

TemperatureThresholdExceeded
  subject: /machines/line-3/oven-2
  data:
    machineId: "oven-2"
    configuredMaximum: 80.0
    measuredTemperature: 82.3
    exceededAt: 2025-09-27T09:14:24.123Z
    severity: "warning"

OverheatingConditionDetected
  subject: /machines/line-3/oven-2
  data:
    machineId: "oven-2"
    temperatureReadings: [82.1, 82.8, 83.2, 83.7, 84.1]
    duration: "15 seconds"
    detectedAt: 2025-09-27T09:14:39.456Z
    severity: "critical"

EmergencyShutdownTriggered
  subject: /machines/line-3/oven-2
  data:
    machineId: "oven-2"
    reason: "overheating"
    triggeredAt: 2025-09-27T09:14:40.001Z
    triggeredBy: "automatic-safety-system"

These are events. They represent facts that matter to the business. Maintenance needs to be notified. Production planning needs to adjust schedules. Quality assurance needs to check whether any products were affected. The safety log needs a permanent record. Insurance might need to be informed. These events have consequences. They trigger workflows. They inform decisions.

The distinction is simple but critical: raw data is collected automatically, regularly, and without specific business intent. Domain events represent facts that are meaningful within a business domain. They capture decisions, state transitions, or occurrences that someone cares about. An event always has intent. It always has business relevance. It always matters to someone.

The Litmus Test: Who Would Care?¶

Over the years, I've developed a simple test to help teams distinguish raw data from domain events. When you're looking at a piece of data being captured by your system, ask this question:

Would anyone want to be notified about this specific occurrence?

If the answer is yes, you're likely dealing with an event. If the answer is no, it's probably just raw data.

Would anyone want to be notified that the GPS coordinate changed from (52.520008, 13.404954) to (52.520012, 13.404961)? No. That's just the car moving 5 meters. But would anyone want to be notified that the driver is now within 500 meters of the pickup location? Yes. The passenger wants to know. The notification service needs to trigger an alert. Multiple parts of the system care about this occurrence.

You can phrase the question in different ways: Does this trigger something? Does business logic follow from it? Would we want to audit this later? Does this represent a meaningful state change? All of these questions point to the same principle: events have consequences. Raw data doesn't.

This litmus test separates signal from noise. Most systems generate vast amounts of data. High-frequency sensor readings. Continuous GPS streams. Click events. Page views. Telemetry. Log entries. The overwhelming majority of that data is noise. Only a small fraction represents events worth preserving in an event-sourced model – the signals that indicate something business-relevant has occurred.

When Event Sourcing Makes Sense¶

Now that we understand what makes something an event rather than just data, let's look at where Event Sourcing truly shines.

Event Sourcing excels when you need to understand not just what the current state is, but how you got there. When the history of changes matters as much as the outcome. When you need to maintain a complete audit trail of who did what and when. When compliance regulations require you to demonstrate exactly what happened and in what order.

It's ideal for systems where change is meaningful, where the history of how something came to be is as important as the current state, and where business logic is complex or evolving.

Think about a bank account. A customer calls three months later disputing a €50 charge. Without Event Sourcing, you might see the current balance and a few recent transactions in a database table. But what happened in March? Was there a withdrawal? A fee? A reversal that was later corrected? You're guessing, reconstructing from partial logs, hoping someone didn't overwrite the audit trail.

With Event Sourcing, you have the complete story: MoneyDeposited, TransferInitiated, FeeCharged, DisputeRaised, RefundProcessed. Every transaction is preserved as an immutable fact. You can replay the account's entire history. You can prove to auditors exactly what happened on March 15th. You can apply new fee calculation rules retroactively to see if they would have changed outcomes. The events are the business. They're not just a technical implementation detail – they're the primary asset, the legal record, the source of truth.

The same pattern appears in healthcare, where patient admissions, diagnoses, treatments, and test results might need to be preserved for decades for legal and medical reasons. Or in order management, where every step from placement through delivery needs to be visible to customers and might be investigated if something goes wrong. In all these domains, the events represent real business transactions and decisions, not just measurements or observations. They have semantic meaning. They're expressed in the language of the domain. And they have ongoing value long after they occur.

For a detailed exploration of where Event Sourcing excels and where it doesn't, see the Use Cases documentation.

When Event Sourcing Doesn't Make Sense¶

Event Sourcing is not appropriate when the data being collected is not being used for anything beyond storage. If you're not actively doing something with the events, if they're not triggering logic, informing decisions, supporting analysis, or fulfilling audit requirements, then they're not really events at all. They're just data being accumulated.

This is the anti-pattern I see far too often: teams that adopt Event Sourcing because they're handling high volumes of incoming data, but without a clear understanding of which parts of that data have business meaning. They confuse "we have a lot of data flowing through our system" with "we need Event Sourcing." The result is predictable: Event Sourcing becomes an expensive and unnecessary abstraction when applied to raw data streams. You get all the complexity (event schemas, versioning, replay logic, projections) without any of the benefits.

Someone once told me they were planning to use Event Sourcing for their application's access logs. Every HTTP request would be an event. Every 404 error. Every redirect. Every static asset load. Millions of events per day. Why? "Because we might want to analyze them later."

But those aren't business events. They're technical telemetry. Yes, you should collect them. Yes, you should store them. But not in your event-sourced business domain. Those belong in a log aggregation system like Grafana Loki or a time-series database like InfluxDB – tools optimized for high-volume writes and temporal queries. Using Event Sourcing for access logs is like using a relational database to store video files. Technically possible, but fundamentally the wrong tool.

Similarly, if your system revolves around static reference data, read-only catalogs, or short-lived records with no historical significance, Event Sourcing is likely to introduce complexity without benefit. Not everything needs history.

The key question remains: Are you capturing events, or are you just collecting data? If it's the latter, Event Sourcing is not the right tool.

Bridging the Gap: From Raw Data to Events¶

But here's the reality: many systems do need to handle both. Your ride-sharing app needs those GPS coordinates to detect when the driver approaches. Your manufacturing system needs those temperature readings to identify overheating. The question isn't whether to collect raw data – it's how to transform it into meaningful events.

The answer is architectural separation with a clear pipeline that transforms raw data into meaningful events.

Raw data should be stored in a system optimized for high-volume writes. This might use a time-series database, a document store, or even a capped collection where old data is automatically discarded. You don't need GPS coordinates from last month. They're ephemeral.

On top of this raw data layer, you implement stream processing using sliding windows, geofencing services, or threshold monitors. This layer watches the raw data stream and looks for business-meaningful patterns. When the driver enters the 500-meter radius around the pickup location, it emits DriverApproachingPickupLocation. When a temperature exceeds the safety threshold, it emits TemperatureThresholdExceeded.

These domain events – and only these domain events – are what you store in your event-sourced system. They are business-relevant, semantically rich, and designed to be preserved and queried over time. Notice the transformation: 600 raw data points became 4 business events. That's the right ratio. You extracted the signal and discarded the noise.

This architecture respects the nature of the data. High-volume raw data ingestion where you need it. Stream processing to extract business meaning. Event Sourcing for the semantically rich facts that have ongoing value. Event Sourcing is optimized for reading and replaying history, not for absorbing millions of raw measurements per second. Don't fight its strengths.

Event Sourcing Is About Meaning, Not Volume¶

Here's the fundamental insight: Event Sourcing is not a data collection strategy. It's a way of modeling and preserving business-relevant facts.

If your primary challenge is handling high volumes of incoming data, Event Sourcing is probably not the answer. You might need a time-series database, a streaming platform like Kafka, or a distributed data ingestion pipeline. Don't force Event Sourcing into a role it was never designed for.

But if your challenge is capturing what happened in your business domain, preserving the history of decisions and state transitions, enabling deep analysis and auditability, then Event Sourcing is exactly the right approach, regardless of whether you have ten events per day or ten thousand.

The difference lies in the nature of the data, not the volume. Event Sourcing is appropriate when you're dealing with domain events: business facts with intention, meaning, and consequences. It's not appropriate when you're dealing with raw data that hasn't yet been interpreted in a business context. Know the difference, and choose accordingly.

Choosing the Right Tool¶

So how do you make that choice in practice? These questions will guide you:

"What are the business-relevant facts we need to capture?" Not technical facts, not measurements, not telemetry, but business facts. Things that domain experts would recognize as significant.

"What decisions and state transitions matter to our domain?" In the ride-sharing domain: approaching the pickup location matters. Arrival matters. Passenger boarding matters. Ride start matters. The 600 GPS coordinates in between don't matter individually.

"Could we explain these occurrences to a domain expert without using technical jargon?" If you can say "the driver arrived at the pickup location" and a domain expert nods and says "yes, that's important," you have an event. If you have to say "the GPS coordinate changed by 0.00004 degrees" and they look confused, you have raw data.

If the answers point to semantically rich, business-meaningful events, then Event Sourcing is worth exploring. You can learn more in the Introduction to Event Sourcing and explore whether your use case is a good fit in the Use Cases documentation.

But if the answers point to mass data collection without clear business semantics, then you're likely dealing with raw data, not events. Design a pipeline that processes that raw data and extracts the business meaning from it. Then apply Event Sourcing to the meaningful facts you derive.

Event Sourcing is powerful, but it's not universal. Understanding when to use it (and just as importantly, when not to) is the key to building systems that are both effective and maintainable.

The title of this post is "Event Sourcing is Not For Everyone." But that's not quite right. Event Sourcing is for everyone – just not for everything. If you're building software that models a business domain, Event Sourcing gives you a way to capture what actually happens in that domain with precision, traceability, and semantic richness. But only if you distinguish between the signal and the noise. Only if you understand that not every byte of data flowing through your system is an event worth preserving.

Know the difference. Choose accordingly. Build systems that model reality, not just collect data.

If you're ready to explore Event Sourcing with a clear understanding of where it fits, the Getting Started guide will walk you through the fundamentals and help you build your first event-sourced application with EventSourcingDB.