Event-driven architecture helps when one completed business fact should trigger independent work without making the original request wait. It adds risk when events become a vague substitute for clear ownership and synchronous contracts.
A useful event is past tense and business meaningful: invoice.paid, member.invited, or workflow.completed. “User service updated row 12” is an implementation detail that creates coupling rather than reducing it.
Good uses
Use events for notifications, analytics, search indexing, webhook delivery, document generation, and follow-up workflows. The initiating action should remain correct even if this secondary work is delayed. The event is a handoff between owners, not a hidden way to make required validation asynchronous.
Keep a source of truth
The service or module that owns the business fact creates the event after its state change commits. Consumers own their own derived state and must be able to replay. They should not reach back into the producer’s internals to reconstruct meaning.
The risks to design for
- Delivery can be delayed or duplicated.
- Consumers may receive events out of order.
- Schemas evolve while producers and consumers deploy independently.
- Debugging needs correlation IDs and clear ownership.
Version event schemas carefully, add fields compatibly, and treat removal as a migration. Maintain idempotency and a replay strategy from the beginning; those are not emergency features.
Do not event everything
Keep a direct API call when a caller needs an immediate answer, one owner controls the operation, and a transaction is the simplest correctness mechanism. A queue does not make a workflow more reliable unless the producer, delivery path, and consumer failure states are deliberately designed.
For the durable handoff pattern, read how to design background jobs that do not lose work.