Event Sourcing & CQRS

In Event-Sourced CQRS systems, command handlers write strictly to append-only event stores, which stream changes asynchronously to update query projection tiers:

• Optimized Read Projections Matrix: Designing projections per query shape:

• Bank Ledger Transfer (Event Sourcing): Balance is never stored directly. Instead, the balance is dynamically computed by summing the stream of credit/debit transaction event logs over time, ensuring auditability.
• E-Commerce Catalog Search (CQRS): Product additions write to a transactional database, while search listings route to Elasticsearch projections, preventing catalog locks.

• Kafka Architecture & Guarantees: Serving as the high-throughput, partitioned event store.
• Distributed Transactions: 2PC vs Saga: Sagas reacting to events emitted from the write store.
• Message Queues Fundamentals: Relaying command events to processing pools.

Dual-Write Consistency Protection: CDC (Change Data Capture)

In CQRS architectures, updating the read projection database directly from the command handler is a dangerous pattern. If the write to the command DB succeeds, but the write to the read DB fails (or vice versa), the system drifts into permanent split-brain state.

**Solution: Change Data Capture (CDC)**

1. The Command Handler writes *only* to the primary relational SQL write database.
2. A CDC engine (e.g., Debezium) tails the database's binary transaction logs (**WAL**) asynchronously.
3. Debezium converts WAL log writes into an event stream and publishes them to a Kafka event topic.
4. Query projection processors consume events from Kafka, updating Elasticsearch search replicas safely.

This completely decouples the write and read tiers, guaranteeing eventual consistency without introducing dual-write failure points.