Event-driven architectures
Events decouple writers from readers. They also hide the call graph. Use them when the domain is already a sequence of facts, not to avoid an API.
Personal experience
On ProCrédito v2 and related ERP work, Laravel services emit facts onto Redis Streams; Python workers consume them for bulk processing. The producer does not wait for every consumer. The domain write still belongs to Laravel.
Technical perspective
Event-driven design is a trade: you buy temporal decoupling and lose a single stack trace. That is a good trade when the producer should not know its consumers — invoicing after an order, search after a catalog change, notifications after a payment.
It is a bad trade when the next step must succeed or the user-facing action is a lie. “Place order” that returns 201 before inventory is reserved is not eventual consistency. It is an incorrect API.
Name events as facts that already happened, in the past tense, with a payload the producer can stand behind. If consumers need to query the producer to understand the event, the event is a ping, not a contract.
Architecture
Facts in, reactions out
Producer
Event log / broker
Consumer A
Consumer B
Consumer C
Technical perspective. Producers emit facts; consumers react without a shared transaction.