Considerations

  • Input
    • Idempotent functions—same output if triggered multiple times
      • Need mechanism to identify duplicate events—key, e.g, for processing payments
    • Event size—sparse vs dense
      • Choose to minimize number of subsequent calls to retrieve more data
      • Balance against message size
        • Large messages increase payload size, and introduce complexity in management of the API contract
  • Output
    • Consider knock-on effects
    • Make every function emit an event, even if there are (currently) no consumers—extensibility

Designing Event Driven Applications

  • Create two tables: one for each service; one for each event.
  • Simpler to understand, maintain and extend than a diagram

Design Table

API (sync)Input EventsServiceActionOutput Event
CreateOrderOrderCreateOrderOrderCreated
CreateOrderInventoryReserveItemItemReserved

’API (Sync)’ column represents the only synchronous call in the application, i.e. the intial API call which triggers the flow.

Event Table

NameAttributesServiceAction
OrderCreatedCustomerId
ProductId
OrderId
OrderCreateOrder
ItemReservedCustomerId
ProductId
OrderId
InventoryReserveItem

Errors

  • Design errors via same method as the happy path designs—emit error events etc.
  • Revert any side effects

Best Practices

  • Keep track of all events in an event log—helps with debugging
    • e.g. in AWS, create a custom bus in Event Bridge, trigger a Lambda function for every event, and store in DynamoDB
  • Use Dead Letter Queues in the event bus

References


Graph View