Event-Driven Architecture Language Exercises — English for Software Architects

A command is an instruction directed at a specific service requesting it to do something (e.g., PlaceOrder), and it may be rejected. An event is a fact that has already occurred and is broadcast to any interested consumers (e.g., OrderPlaced) — it cannot be refused. This distinction is central to CQRS and event sourcing design, and engineers use it to decide whether an interaction should be imperative or declarative.

Event sourcing stores all changes to application state as an ordered sequence of immutable events rather than as a current snapshot. Engineers describe it by saying "the event log is the source of truth" and "the current state is a projection of all past events". The key benefit is a full audit trail; the key trade-off is the complexity of rebuilding state through event replay and managing eventual consistency of projections.

CQRS stands for Command Query Responsibility Segregation — it separates the write model (commands that mutate state) from the read model (queries that return data). Engineers advocate for it when read and write workloads have significantly different scaling or data-shape requirements, using phrases like "we have separate write and read stores" or "the read model is a denormalised projection updated by event handlers".

Eventual consistency means that, given no new updates, all replicas or read models will converge to the same value — but there may be a window where different consumers see different states. Engineers communicate this by saying "the read model lags behind the event stream by a few milliseconds" or "we accept eventual consistency here because strict consistency would require synchronous calls across service boundaries".

The outbox pattern solves the dual-write problem — the risk of writing to a database and publishing an event to a message broker atomically. Instead of publishing directly, the service writes the event to an outbox table in the same database transaction, and a separate relay process (often using change data capture) publishes it to the broker. Engineers describe it as "guaranteeing at-least-once delivery without distributed transactions".

In a choreography-based saga, each service reacts to events and emits its own events without a central coordinator, while in an orchestration-based saga, a central orchestrator directs each step. Engineers prefer choreography for loose coupling but switch to orchestration when the business process is complex and needs a single place to observe and compensate, using phrases like "we need an orchestrator to handle partial failure rollback".

In Apache Kafka, a topic is divided into partitions for parallel processing, and each partition is assigned to exactly one consumer within a consumer group at a time. Engineers use this to scale consumers horizontally — "adding more consumers to the group will increase throughput up to the partition count" — and describe offset management as the mechanism by which consumers track which messages they have processed.

A Dead Letter Queue is a special destination for messages that cannot be processed successfully after a maximum number of retry attempts. Engineers use it as a safety net, saying "failed messages land in the DLQ for manual inspection or replay" — it prevents poison messages from blocking a queue indefinitely while preserving the payload for diagnosis and remediation.

Schema evolution refers to changing the structure of events over time without breaking existing consumers. Engineers use backward compatibility (new consumers can read old events) and forward compatibility (old consumers can read new events) as design targets, enforced by a schema registry with Avro or Protobuf. The vocabulary includes "additive change" (safe to add optional fields) and "breaking change" (renaming or removing required fields).

At-least-once delivery guarantees a message will be delivered but may be delivered more than once in the event of retries, requiring consumers to be idempotent. Exactly-once delivery guarantees each message is processed precisely once, which Kafka supports for producer-to-broker writes using idempotent producers and transactional APIs. Engineers note that exactly-once "end-to-end" across services is much harder to achieve than within a single Kafka cluster.