Article illustration 1

The GPS‑Coordinate Conundrum

A recent LinkedIn post by Martin Dilger sparked a private debate: Are a driver’s GPS coordinates events? In a typical ride‑sharing trip a vehicle might emit a GPS point every second, producing 600 data points over ten minutes. The instinct is to treat each point as an event because it is a timestamped fact. However, the coordinates themselves are raw sensor data—measurements that lack inherent business meaning.

The real business events in that scenario are:

  • DriverApproachingPickupLocation – when the driver enters a 500‑meter radius.
  • DriverArrivedAtPickupLocation – when the vehicle stops at the meeting point.
  • PassengerBoarded – when the passenger enters the vehicle.
  • RideStarted – when the journey officially begins.

These events carry intent, trigger downstream logic, and are the facts that billing, insurance, and analytics services consume.

Raw Data vs. Domain Events

Raw data is collected automatically, at high frequency, and without a business purpose. A temperature reading of 82.3 °C at 09:14:23.847 is a measurement, not a business fact. By contrast, a TemperatureThresholdExceeded event indicates a meaningful state transition that triggers maintenance, safety protocols, and audit logs.

The Litmus Test

Ask: Would anyone want to be notified about this occurrence? If the answer is yes, it is likely a domain event. If no—such as a minute‑to‑minute GPS shift—then it is raw data.

When Event Sourcing Truly Shines

Auditability and compliance are the primary drivers for event sourcing. Banking systems, healthcare records, and order‑to‑delivery pipelines all benefit from a complete, immutable history. Event sourcing allows replaying the entire state transition sequence, proving exactly what happened on a given date, and retroactively applying new business rules.

When It Doesn’t Make Sense

High‑volume telemetry—access logs, click streams, or continuous sensor feeds—should be stored in time‑series or log aggregation systems, not in an event‑sourced domain store. Treating every HTTP request as an event adds unnecessary complexity and storage overhead without delivering business value.

Bridging the Gap

Architectural separation is key:
1. Raw Data Layer – ingest high‑frequency streams into a time‑series database or capped collection.
2. Stream Processing – apply sliding windows, geofencing, or threshold monitors to detect business‑meaningful patterns.
3. Event Sourcing Layer – persist only the distilled domain events that have intent and consequence.

This pipeline preserves the signal while discarding the noise, ensuring that event sourcing remains focused on meaningful facts.

Choosing the Right Tool

Ask yourself:
- What business‑relevant facts must we capture?
- Which state transitions matter to domain experts?
- Can we describe these occurrences without technical jargon?

If the answers point to semantically rich events, event sourcing is justified. If they point to bulk data collection without clear business semantics, design a separate ingestion and processing pipeline.

Bottom Line

Event sourcing is powerful, but it is not a one‑size‑fits‑all solution. Distinguishing raw data from domain events, applying a clear architectural separation, and aligning the model with real business needs will keep systems both effective and maintainable.

Source: https://docs.eventsourcingdb.io/blog/2025/11/27/event-sourcing-is-not-for-everyone/