Your event terminology is probably wrong—and it's costing you coupling

Jacqui Read cuts through the confusion around event-driven architecture terminology, starting with the fundamental distinction between events and commands. Events are immutable facts that have already happened, while commands express intent and expect action. This distinction has direct consequences for transaction boundaries and system coupling.

The talk then moves into streaming versus queuing, emphasizing that message logs preserve offset-based consumption history while queues remove consumed messages. Read highlights how event-driven architectures create an "ivy wall" where dependencies become invisible, making change impact analysis much harder than in monolithic systems.

Event sourcing gets practical treatment with the git analogy—storing state changes rather than current state enables time travel debugging and audit trails. GDPR concerns are addressed through encryption key deletion rather than data deletion. The tradeoff between storage costs and debugging ability is left for teams to evaluate.

The most operationally useful section covers event granularity: too small creates chatty systems requiring callbacks, too large increases coupling and leaks business rules. Read advocates for "as large as necessary, as small as possible," a practical heuristic that balances autonomy with information completeness.