Events Unleashed

Explore the fundamentals and advantages of Event-Driven Architecture (EDA) in this practical talk. We'll cover how this approach enables more scalable, reactive, and flexible systems where actions are triggered by events. Learn best practices, challenges, and use cases that highlight EDA's efficiency in contexts like IoT, microservices, and real-time data processing. Ideal for developers and architects looking to optimize workflows and enhance system resilience.

Transcript

1. Events Unleashed Taming Event-Driven Architecture
2. Éverton Carlos Software Engineer – 5x AWS – MBA in Project IT Management everton.nunes@zup.com.br (34) 9.9263-0888 /evertoncnsouza
3. Events Unleashed Taming Event-Driven Architecture
4. Importance of Event-Driven Architecture 02 Flexibility 04 Decoupling 01 Scalability 03 Responsiveness
5. Real World Cases Companies using event-driven architecture
6. ➔ Common Patterns ➔ Best Practices AGENDA ➔ Basic Concepts ➔ Idempotency ➔ Conclusion and Questions ➔ Considerations with event-drive architectures
7. Basic Concepts
8. Event-Driven Event-Driven Architecture is a software architecture model where system components communicate primarily through events. This approach enables components to be decoupled and highly responsive to changes.
9. ➔Events An event is a significant occurrence or a state change detected by the system. Events act as triggers that initiate actions or workflows within the architecture. Event-Driven Event-Driven Architecture is a software architecture model where system components communicate primarily through events. This approach enables components to be decoupled and highly responsive to changes.
10. Events can be generated from various sources, such as state changes in an application, user actions, data modifications, or notifications from external systems. Each event contains information about what occurred, when it happened, and often includes additional relevant data. How are events generated ?
11. Events can be generated from various sources, such as state changes in an application, user actions, data modifications, or notifications from external systems. Each event contains information about what occurred, when it happened, and often includes additional relevant data. Events are signals that a system’s state has changed Signals How are events generated ?
12. Events can be generated from various sources, such as state changes in an application, user actions, data modifications, or notifications from external systems. Each event contains information about what occurred, when it happened, and often includes additional relevant data. Events are signals that a system’s state has changed Signals Events occur in the past (e.g., OrderCreated) In the Past How are events generated ?
13. Events can be generated from various sources, such as state changes in an application, user actions, data modifications, or notifications from external systems. Each event contains information about what occurred, when it happened, and often includes additional relevant data. Events are signals that a system’s state has changed Signals Events occur in the past (e.g., OrderCreated) In the Past Events are immutable (cannot be changed) Immutable How are events generated ?
14. Events can be generated from various sources, such as state changes in an application, user actions, data modifications, or notifications from external systems. Each event contains information about what occurred, when it happened, and often includes additional relevant data. Events are signals that a system’s state has changed Signals Events occur in the past (e.g., OrderCreated) In the Past Events are immutable (cannot be changed) Immutable Events are observed, not directed. Observed How are events generated ?
15. Producers These are components or services that generate and publish events. Any state change or significant action within the system can trigger an event. For example, a payment service can be an event producer when a payment is processed.
16. ➔Consumers These are components or services that listen for and react to events generated by producers. They perform specific actions when certain events are detected. For instance, a notification service can be an event consumer that sends a confirmation email when a payment is Producers These are components or services that generate and publish events. Any state change or significant action within the system can trigger an event. For example, a payment service can be an event producer when a payment is processed.
23. ➔ Broadcast events ➔ Aggregation events ➔ Etc…. TYPES OF EVENTS ➔ State change events ➔ Data log events ➔ Command Events ➔ System Integrity Events
24. Common Patterns
25. Point-to-point-messaging ➔ Decreases temporal and location coupling ➔ Resilient to receiver failure ➔ Receiver control consumption rate ➔ Only one receiver can consume each message
26. Event Streaming ➔ Decreases temporal and location coupling ➔ Resilient to receiver failure ➔ Continuous flow of messages (real-time) ➔ Can be processed individually or together
27. Pub/sub messaging (Topic) ➔ Decreases temporal and location coupling ➔ Push-based ➔ Fan-out: send the same message to N receivers
28. Pub/sub messaging (Bus) ➔ Decreases temporal and location coupling ➔ Advanced routing / filtering ➔ Hub & Spoke: send the same message to multiple receivers
29. Choreography and Orchestration
30. Combining patterns
31. Choreography and Orchestration
32. Fan-out & Topic-Queue Chaining
33. Filtering & Routing to SQS for persistence
34. Considerations with event-driven architectures
35. Eventual consistency ➔ Decentralized data management ➔ Asynchrony and user interface
36. Idempotency ➔ At least once delivery and duplication handling
37. Best Practices
38. ➔ Design idempotent events ➔ Avoid overly large events (or excessive event Sourcing) ➔ Implement monitoring and event tracking ➔ Define events clearly ➔ Minimize coupling ➔ User proper persistence and retries Best Practices ➔ Consider event schema evolution ➔ Plan for scalability ➔ Implement DLQs ➔ Define delivery guarantees
39. Conclusion and Questions
40. Thank you!
41. Éverton Carlos Software Engineer – 5x AWS – MBA in Project IT Management everton.nunes@zup.com.br (34) 9.9263-0888 /evertoncnsouza