Events

Commands ask for something to happen; events state that it did. What that distinction changes about coupling, naming, consumers and the consistency of everything downstream.

Commands vs Events

A command asks for something to happen and has exactly one handler; an event states that something happened and has any number of consumers.

Q · What actually changes when I stop telling a service what to do and start telling it what happened?
Event-Driven Backends

Publishing a fact instead of calling the next step, what that actually buys, and the honest list of what it costs.

Q · What does my backend gain, and pay, by publishing an event instead of calling the next step directly?
Naming Events

Past-tense domain facts decouple; procedural names smuggle the consumer's behaviour into the producer.

Q · Why is `OrderCreated` a better event name than `ProcessOrderEvent`, and what breaks when I get this wrong?
Writing Event Consumers

A consumer is a program that will see every message twice, some out of order, and one that poisons it.

Q · What does a correct event consumer have to handle that a request handler does not?
Keeping a Search Index in Sync

Database change to event to indexer to search engine — and the fact that when it breaks, nothing errors and search is quietly wrong.

Q · How does a search index stay consistent with the database, and how would I even know that it had not?
Eventual Consistency in Practice

Once work happens after the response, some reads are stale — and the engineering is in bounding it, showing it honestly, and knowing when it has stopped converging.

Q · My write returned 200 and the next read does not reflect it. Is that a bug, and what do I owe the user?