CQRS and Event Sourcing with Streaming SQL

Microservices traditionally communicate via synchronous HTTP APIs or asynchronous message queues. Event-driven communication with a streaming database adds a third option: services publish events to Kafka, and a streaming database maintains cross-service materialized views that any service can query.

Architecture

Service A → Kafka (order events) → RisingWave → Cross-service views
Service B → Kafka (payment events) →              ↓
Service C → Kafka (shipping events) →     Query via PostgreSQL

-- Unified order status combining events from 3 services
CREATE MATERIALIZED VIEW order_status AS
SELECT o.order_id, o.customer_id, o.amount,
  p.payment_status, p.paid_at,
  s.shipping_status, s.tracking_number
FROM order_events o
LEFT JOIN payment_events p ON o.order_id = p.order_id
LEFT JOIN shipping_events s ON o.order_id = s.order_id;

Any service queries order_status for the complete picture — no service-to-service API calls.

Frequently Asked Questions

How is this different from an API gateway?

An API gateway routes requests to services. A streaming database pre-computes cross-service views from events. The key difference: no runtime API calls between services. The view is always ready.

Does this create a single point of failure?

The streaming database is a read model, not the source of truth. If it goes down, services still communicate via Kafka. The read model rebuilds from Kafka events when it recovers.