Auditing, Debugging and Temporal Queries — Event Sourcing & CQRS

With complete event histories you can answer: what did this account look like on March 1, who changed what and why (metadata: user, correlation ID, causation ID, client IP), and how did a bug corrupt state. Store rich metadata with each event, build tooling to inspect streams, and use temporal replays to reproduce production issues in tests. Combine with retention and access controls — history is sensitive.

Event metadata for audit

Metadata field	Answers
user_id / actor	Who did it
correlation_id	Which request/workflow
causation_id	Which event/command caused it
client / IP / app version	From where
reason	Why (business justification)

-- State of account 42 on 2026-03-01: replay events recorded before that time
SELECT event_type, data, metadata->>'user_id' AS actor, metadata->>'correlation_id' AS correlation
FROM events
WHERE stream_id = 'account-42' AND recorded_at < '2026-03-01'
ORDER BY stream_version;

Common pitfalls

Events without actor/correlation metadata.
No tooling to browse streams (history unusable in practice).
Unrestricted access to sensitive histories.

Key points

Rich metadata on every event
Temporal replay for debugging
Access control on history

Further reading: EIP: Correlation Identifier

Practice questions

What's the difference between correlation ID and causation ID?

Answer

Correlation ID ties all messages of one business flow together; causation ID points to the specific message that directly caused this one, forming a chain.

How does event sourcing help reproduce production bugs?

Answer

You can replay the exact sequence of events that led to a bad state in a test environment and step through the logic.