Event Sourcing Integration

Event sourcing stores changes as an ordered stream of facts rather than repeatedly overwriting the latest state. Instead of persisting "cart total is €42", the system records events such as ItemAdded, QuantityChanged, and DiscountApplied. Current state is reconstructed by replaying those events in order. That sounds simple, but it changes the storage model, the integration model, and the operational model at the same time.

The event log becomes the source of truth

In an event-sourced system, the append-only log is authoritative. Read models, search indexes, analytics tables, and caches are derived views. This is powerful because one durable history can feed many projections for different needs. A billing projection can care about tax events and settlement status, while a customer view can care about basket contents and order progress.

The core constraint is event quality. Events must describe domain facts clearly, be immutable once published, and carry enough metadata to support replay, audit, and idempotency. Poorly named or ambiguous events poison every downstream consumer because you cannot silently rewrite history without breaking reproducibility.

Model streams around aggregate boundaries

Most practical designs group events by aggregate or entity, such as one stream per cart, account, or order. Ordering is then guaranteed within that stream, not across the entire system. This keeps writes scalable and makes optimistic concurrency possible. A writer can append only if the stream is still at the expected version.

Snapshots are often added for efficiency. Replaying ten events for an order is trivial. Replaying two million events for a long-lived account on every read is not. A snapshot is a cached state at a known event position, after which replay continues from that point. The snapshot is an optimisation, not a new source of truth.

Projections give you usable read models

Users and other services rarely want to replay raw events themselves. Projection workers consume the log and build query-friendly views: relational tables, document stores, search indexes, or warehouse feeds. Those views are typically eventually consistent. A freshly written event may not appear in a projection for a short period, which means the product must tolerate read-after-write lag where needed.

Projection code must be idempotent. Replays, retries, and backfills happen routinely. If a worker processes PaymentCaptured twice, the downstream view must remain correct. This usually means storing the last applied event position or making updates safe to repeat.

Schema evolution is the long-term cost

Event sourcing preserves history, so schema changes stay with you. New code must often read old event versions for years. Upcasters, versioned event handlers, or migration replays are common tools, but they add operational discipline. You also need retention and privacy rules. Immutable history is awkward when regulations or business policy require selective erasure of personal data.

Another common mistake is calling every message stream event sourcing. A broker such as Kafka can transport events, but transport alone is not event sourcing. The design only counts if the ordered event history is the canonical record from which state can be rebuilt.

When it fits

Event sourcing fits domains where history matters as much as current state: financial ledgers, order lifecycles, workflow systems, audit-heavy business processes, and collaborative systems that benefit from replay. It is especially useful when several downstream models need the same source events.

It fits poorly when the domain is simple, history has little value, or the team cannot support replay, versioning, and eventual consistency. In those cases a conventional state store plus audit log is often cheaper and easier to operate.