#
CQRS (Command Query Responsibility Segregation) separates write operations (commands) from read operations (queries). Event sourcing stores all state changes as an immutable event log. Together, they create an architecture where streaming materialized views serve as the read model — continuously updated from the event log.
CQRS with Streaming SQL
Commands → Event Store (Kafka) → RisingWave → Materialized Views (Read Model)
↓
Applications query via PG
-- Event stream (write side)
CREATE SOURCE order_events (...) WITH (connector='kafka', topic='order-events', ...);
-- Read model (automatically maintained)
CREATE MATERIALIZED VIEW order_summary AS
SELECT order_id, last_value(status ORDER BY ts) as current_status,
SUM(amount) as total_amount, COUNT(*) as event_count
FROM order_events GROUP BY order_id;
The read model updates in real time as events arrive. No manual synchronization needed.
Frequently Asked Questions
Why use CQRS with streaming?
CQRS with batch read models requires periodic rebuilds. Streaming materialized views maintain the read model continuously — eliminating stale reads and rebuild jobs.
Is event sourcing required for CQRS?
No, but they pair naturally. Event sourcing provides the immutable event log; CQRS separates read and write concerns. Streaming SQL bridges them by continuously materializing the read model from events.
