Mia-Platform - Event Sourcing and CQRS

Mia-Platform article on combining Event Sourcing and CQRS to resolve each pattern’s individual weaknesses, with a Kafka-based Fast Data platform implementation.

Summary

The article’s central argument is that ES and CQRS each have individual weaknesses that the other pattern resolves, making their combination more powerful than either alone. Event Sourcing alone makes reads expensive: reconstructing current state from events requires replaying the entire event history, which does not scale for high-frequency reads. CQRS alone lacks a natural audit trail: the write side records current state, not state transitions, so historical reasoning requires separate audit logging infrastructure. Combined: ES handles the write side (the immutable event log is the authoritative record of everything that has happened), and CQRS handles the read side (projections build denormalized, optimized read models from the event stream asynchronously).

The Kafka-based implementation uses Kafka as the transport layer between event producers and projection consumers. Events are written to Kafka topics by command handlers; projection consumers read events and update Single Views — domain-specific denormalized read models that aggregate data from multiple event streams into a single queryable document. This is Mia-Platform’s “Fast Data” platform pattern, designed for high-throughput event processing.

The audit compliance angle is practically important: because every state change is captured as an immutable event, regulatory audit requirements (show all changes to a financial record, reconstruct state at a specific point in time) are satisfied as a natural consequence of the architecture, not through separate audit logging infrastructure.

Key Arguments

• ES alone makes reads expensive: full event replay for every read does not scale
• CQRS alone lacks a natural write-side audit trail: current-state storage loses state transition history
• Combined: ES handles authoritative writes (event log), CQRS handles reads (denormalized projections)
• Kafka enables async projection building at scale: projection consumers process events independently at their own pace
• Single Views are domain-specific denormalized read models — one per bounded context query pattern
• Audit compliance is a natural consequence: every change is an event, providing a complete immutable history

Concepts Covered

• Event Sourcing and CQRS Integration — primary treatment; the best single article on the combined pattern
• Event Sourcing — write-side role; the immutable event log as the authoritative record
• CQRS — read-side projections; Single Views as denormalized query models
• Apache Kafka — transport layer for async event distribution to projections
• Eventual Consistency — read model consistency; projections lag behind the event log

Quality Notes

Best single article on the combined ES+CQRS pattern and why the combination resolves individual weaknesses. The Kafka-based Fast Data implementation provides a concrete architecture reference. April 2025 publication date means this is current and reflects modern platform patterns.