Event-Driven Architecture — Vocabulary and Communication

Event: 'OrderPlaced' — something already happened, the publisher doesn't care who handles it. Command: 'ProcessPayment' — an instruction to a specific service to do something. Events decouple publisher and subscriber; commands create a direct relationship. Event-driven systems prefer events for loose coupling; commands for explicit orchestration.

Saga: distributed transactions without a two-phase commit. Choreography-based saga: each service publishes events that trigger the next service. Orchestration-based saga: a central coordinator tells each service what to do. If any step fails, compensating transactions undo previous steps. Example: Order placement saga — PlaceOrder → ReserveInventory → ChargPayment → ConfirmOrder.

Outbox pattern solves the dual-write problem: you cannot atomically write to a database AND publish to Kafka/RabbitMQ. Solution: write to both the business table AND an 'outbox' table in one database transaction, then a Debezium CDC process reads the outbox table and publishes to the message broker. This guarantees at-least-once delivery without distributed transactions.

Event sourcing: instead of storing 'balance = 500', store [AccountOpened(initial=1000), Deposited(200), Withdrawn(700)]. The current state (balance=500) is derived by replaying events. Benefits: complete audit history, ability to rebuild state at any point in time, enables event-driven integration. Trade-off: query complexity (need projections/read models).

At-least-once: the broker retries until the consumer acknowledges — but network failures can cause the same message to be delivered twice. Consumers must be idempotent. Exactly-once: extremely difficult to guarantee across distributed systems; Kafka Transactions attempt this for Kafka-to-Kafka flows. In practice, most systems implement at-least-once with idempotent consumers.