In event-driven architecture, services communicate by producing and consuming events (something happened: “OrderPlaced,” “UserSignedUp”). Producers publish to a broker (Kafka, etc.); consumers subscribe and react. This decouples producers from consumers and allows multiple consumers to react to the same event.
| Benefit | Trade-off |
|---|---|
| Loose coupling | Eventual consistency; harder to trace |
| Multiple consumers | Ordering and exactly-once need care |
| Scale consumers independently | Operational complexity (broker, schemas) |
Event — “Something happened” (past tense). Multiple subscribers. Command — “Do this” (imperative). Often one handler. Events are the backbone of event-driven systems; commands can be sent over queues for point-to-point work.