-
Event - Events are immutable. Something that happened in the past.
-
Producer - Creates Events
-
Consumer - reacts to Events
-
Channel - service/mechanism that events flow through
-
Idempotency - if the same event is processed more than once, it will not cause unintended or duplicate effects on the system. Implemented via unique identifiers.(e.g. pushing an elevator button)
Response Models (how to communicate / process events)
- Synchronous (1:1) - AWS API Gateway - must respond within 30 seconds
- Async queue (1:1) - AWS SQS - latency due to polling model, 256KB message size,
- Broadcast (1:N) - AWS SNS (Simple Notification Service)
- Async bus - Event Bus Routing (N:N) - AWS EventBridge -
- Async router - Multi-Model Event Routing (N:N) -
Change Data Capture Events
Notes:
- Why EDA? Reduce complexity of an application, breaking it down, communicating between blocks by Events?
- REST based architecture with CRON for periodic wakeups instead use Events to react
- Embrace Eventual consistency
============================================
Coordinate process flows in a Distributed application
- Using Event Driven Architecture
- Using AWS Step functions
============================================
4 practical examples
- External integrations
- Workflows (Event choreography - way to execute a long running process)
- State transfer
- Temporal decoupling
============================================
Pub-sub model
Pros:
- Decoupling of Publisher - Subscriber
- Dependency inversion - both pub/sub are dependent on an abstraction
- Scalability
Cons:
- Eventual consistency - two people ordering the last item. Use cache.
- Duplicate messages - broker doesn't checkpoint at a very granular level so when a subscriber goes down and comes back it might receive an already processed message - Use Idempotency to mitigate - Unique id in the event
- More complex - harder to debug
References: