Skip to main content
Data Foundations · Playbook · 3 min read

Architecting for Real-Time Decisions with Event Sourcing

Capturing every business event allows for both real-time insights and perfect auditability. For fraud detection and instant credit approvals, we implement event sourcing.

Most systems store state and lose history. A customer’s credit-risk profile is updated nightly; tomorrow’s update overwrites tonight’s. By the time a regulator asks “what did you know on the 14th of March, and when did you know it”, the answer is buried in backups — if it exists at all. The cost of state-only storage is opacity: you have the current view, but you cannot reconstruct why a decision was made, when the inputs changed, or what alternative state existed seconds before the choice was committed.

Event sourcing inverts the storage default. Instead of persisting the current state, the system records the immutable sequence of events that produced that state — a TransactionOccurred here, a CreditApplicationSubmitted there, an AlertTriggered elsewhere — and derives the current state by replay. The cost is upfront architectural discipline. The payoff is a system that can answer the regulator’s question in seconds and run real-time decisioning on the same substrate.

The architectural disciplines that make event sourcing pay off

Event sourcing fails when teams treat it as a database choice rather than an architectural commitment. The patterns below are what we hold to in client implementations where regulatory auditability and sub-second decisioning have to coexist.

Immutable events are the system of record; everything else is a derived view.

The event log is append-only, durable, and the canonical history. Read-side projections (a customer-360 dashboard, a fraud feature store, a regulatory report) are rebuilt from the events when needed. The temptation to “just fix the data” by updating an event in place destroys the entire audit guarantee; we handle corrections via compensating events that themselves enter the log.

Stream processing is a data layer, not an integration layer.

The decision engines, feature stores, and fraud rules consume the same stream the audit system reads. Kafka or Kinesis carries the events; Flink or Spark Streaming handles the windowed aggregations. The latency budget is set by the business decision (a credit approval needs ~200ms; a fraud alert can tolerate ~2s), not by the tooling defaults.

Time-travel queries are built in, not bolted on.

Replaying the event log to reconstruct an entity’s state at a moment in the past is the killer feature of event sourcing — and the most commonly mis-implemented. We index events by entity plus timestamp and provide a query API that answers “what did this customer’s risk profile look like at 14:32 on 15 March” without engineering intervention.

The harder discipline underneath these three is event design. Events that mirror database CRUD operations (CustomerUpdated, RecordChanged) carry no business meaning and degrade into the same opacity as state storage. Events that mirror business intent (TransactionOccurred, CreditApprovalGranted, KYCRefreshCompleted) preserve the why alongside the what, and that is what makes the log valuable years after the writing engineer has left.

Three architectural components

Storage layer

Immutable event logs

We design immutable events for core business domains (e.g. TransactionOccurred, CreditApplicationSubmitted), creating a permanent, auditable record of every action.

Deliverable A single source of truth that can't be quietly mutated.

Processing layer

Scalable stream processing

We use tools like Kafka or Kinesis with appropriate stream-processing patterns (Flink, Spark Streaming) to handle thousands of events per second, feeding real-time feature stores and decision engines.

Deliverable Sub-second decisioning on live event streams.

Query layer

Time-travel queries

We build the capability to reconstruct the state of any entity (e.g. a customer’s risk profile) at any point in time — a critical requirement for regulatory inquiries.

Deliverable 30-second answers to "what did you know, and when".

A caveat

Event sourcing is expensive in upfront discipline and read-side complexity. For reporting systems where state is sufficient and audit needs are met by change-data-capture on a relational store, the cost is not justified. For decision systems where regulatory reconstruction or real-time feature engineering is on the path, the cost is paid back many times over. The Data Foundations pillar we run with clients includes the architectural-decision diagnostic that determines whether event sourcing is the right substrate.

Go deeper

Strategic Guide to Modern Data Platform Transformation

Our standalone playbook on modern data platform transformation — dbt architecture for regulated data, governance integration, semantic-layer design, and migration sequencing. Free, delivered by email.

More from Data Foundations

All insights →
Want this applied to your context?

Let's talk about where you are and where this would land.

Thirty-minute discovery call — no deck, no pitch. We'll talk about where you are and where the highest-impact next move is.

Explore Data Foundations