Messaging, Events and Email Systems · Event-Driven Architecture
Designing Events
Events vs commands, event shapes and schema evolution.
Commands ask a specific service to do something ("ChargePayment") and can be rejected; events state facts that happened ("PaymentCharged") and can have many consumers. Name events in past tense, include an ID, type, timestamp, source, schema version and the data consumers need (or a reference to fetch it). Choose thin events (IDs, consumers fetch details — fresher but coupled) or fat events (full state — autonomous consumers, bigger payloads). Evolve schemas compatibly via a registry.
{
"specversion": "1.0",
"id": "evt_01J9ZM4Q...",
"type": "com.example.orders.order.paid.v1",
"source": "/orders-service",
"time": "2026-10-10T09:15:02Z",
"subject": "ord_8812",
"datacontenttype": "application/json",
"data": {"order_id": "ord_8812", "customer_id": "cus_19", "total": {"amount": 2400, "currency": "EUR"}}
}
Common pitfalls
- Events that are really commands in disguise.
- Leaking internal table structures as events.
- Breaking schema changes without versioning.
Key points
- Commands request; events state facts
- Thin vs fat events trade-offs
- CloudEvents envelope; schema registry
Further reading: CloudEvents
Practice questions
What's the difference between a command and an event?
Answer
A command is a request directed at one handler that may be rejected; an event records something that already happened and may be consumed by any number of subscribers.
When would you prefer fat events?
Answer
When consumers should work autonomously without calling back the producer (availability, load), and the data is not too large or sensitive.
Open in the app to mark lessons complete, take notes and track your progress.