best practices to design and build event-driven architecture
Abstract
event-driven architecture can get confusing very fast, with all the boxes and arrows. Often, when we want to add new behavior, we will not use an existing event, but create another one. The speaker gave those considerations when designing a service with event-driven architecture
- input: which events I listen to
- ensure event uniqueness
- idempotency: operation will return the same results whether it is called once or multiple times
- idempotency key: assigned to the message by the sender to simplify deduplication by the receiver
- internal: what I do with the events
- sparse events vs full state descriptions: find the right balance
- sparse events may trigger multiple calls to the service to get the details of the resources
- full state description: events should be backwards compatible
- output: which events I produce
- instead of a diagram with boxes and arrows, create a table
| API (sync) | Input Events | Service | Action | Output events |
|---|---|---|---|---|
| CreateOrder | Order | CreateOrder | OrderCreated | |
| OrderCreated | Inventory | ReserveItem | ItemReserved ItemNotAvailable | |
| ItemReserved | Inventory | DescribeItem | ItemDescribed |