The document discusses building event-driven systems and the evolution from synchronous request-response architecture to event-driven architecture (EDA), emphasizing the significance of events in enterprise systems. It outlines key components, principles, and patterns of EDA, including the event mediator and broker patterns, which are essential for orchestrating processes and distributing message flow. Additionally, the document links EDA to trends like the Internet of Things and microservices architecture, highlighting the need for reactive design to enhance system scalability and adaptability.

1. Building Event Driven
Systems
Shiroshica Kulatilake
Solutions Architect

2. Setting Expectations
o Today’s Enterprise Systems and how events fit in
o What is Event Driven Architecture
o Patterns for building Event Driven Systems
o Summarize

3. Enterprise Systems & Events

4. Enterprises Today
o Distributed
- Functionality is broken down into several sub systems
- Located in multiple places
o Ubiquitous
- Based on parties interacting through different means
o Connected
- Built based on synergies
- Own as well as partner systems need to interact with each
other efficiently

5. Events in Enterprise Systems
o Occurrence within the context of interest
o A series of events depicting one event in the real world
- e.g. A customer placing an order in a retail system
o Not all events are of interest
o Most everyday events can be dealt in an asynchronous manner
o Occurrence of an situation (relevant event) requires something to
react to it - to move from one state to another
o For this events should be detected, situations filtered and
processes notified
o Leads to Event Driven Architecture

6. Event Driven Architecture

7. Evolution
o SOA
- Synchronous request response systems with asynchronous
message delivery
- Technically loosely coupled
- Functionally tightly coupled
- Mostly centralized
o Evolving into EDA
- Based on message driven model for information propagation
- Spatial and temporal decoupling
- Analogous to the operational model of an organisation where a
series of events take place
o Suited where
- Distributed environments
- Higher level of autonomy is needed at unit level

8. Main Components
o Event - significant happening which results in change of state from
a business perspective
o Event generator- publishes events
o Event processor- consumes events and decide what to do
o Event channel - medium where event lies before consumption

9. Principles
o Immediate information dissemination and reactive business
process execution
o Fire and forget - push based mechanism
o Single responsibility at practice
o Autonomous messages for the receiver to process
o Higher decoupling - no need to bind to contracts
o Logical decoupling of functional units - not dependent and less
impact from change
o Receiver driven flow control - more responsibility lies with receivers
o Near real time information consistency

10. Advantages
o Effective data integration
o Low latency of information
o High reactiveness
o More accurate responses
o High flexibility
o Higher business agility

11. Generic EDA Pattern

12. Event Mediator Pattern
http://radar.oreilly.com/2015/02/variations-in-event-driven-architecture.html

13. Event Mediator Pattern
o Need to orchestrate multiple steps
o Orchestration happens through a central mediator
o Multiple steps need to happen in a certain order
o Processing will be done by separate entities which need to be
invoked in many ways
o Fits scenarios which are complex, have some sort of orchestration
logic and approval tasks etc as well

14. Broker Pattern
http://radar.oreilly.com/2015/02/variations-in-event-driven-architecture.html

15. Broker Pattern
o Message flow is distributed across several processors with no
orchestration
o Fits for use cases where the flow is entirely dependent on event
receiving with no timing
o Once a processor is done with processing another event will be
fired to the broker which will be consumed by another processor

16. Components in an Event Driven System
o Process Engine
o Mediation Engine
o Message Broker
o Business Activity Monitor
o Complex Event Processor
o Business Rules Manager

17. Patterns in building Event Driven
Systems

18. Centralized Message Driven System

19. Sample Solution

20. Sample Extended Solution

21. Autonomous Message Driven System

22. Sample Solution

23. Sample Extended Solution

24. Request Rate Controlling

25. Guaranteed Delivery - Directly via Broker

26. Guaranteed Delivery - via Mediation Engine

27. Guaranteed Delivery - Fault Handling

28. Monitoring and Alerting

29. Keeping up with the trends

30. Internet of Things (IoT)

31. Internet of Things (IoT)
o There exists a plethora of devices which provide data in several
contexts
o This data needs to be captured in order to analyze and derive
intelligence and then take actions
o Point to point integration with each device is not a possibility
o Leads to the use of Event Driven Architecture through the use of
protocols which work on publish-subscribe mechanisms - e.g.
MQTT and also through handling large scale event analyzing

32. Internet of Things (IoT)

33. Microservices Architecture

34. Microservices Architecture
o Microservices promote distributed data management
o Data in microservices
- Are private to a specific microservice
- Use polygot persistence
- Might not expose generic APIs for all possible modes of use
o However, business transactions span multiple microservices
which would need accessing private data of other microservices
o Leads to the use of Event Driven Architecture where distributed
data management is handled through the use of events
o Variants are event tables, transaction log mining and event
sourcing which try to reduce errors relating to atomicity

35. Microservices Architecture

36. Reactive Architecture

37. Reactive Architecture
o To achieve being reactive, systems should be designed with
containment of functionality in mind so that scaling, isolation of
failures and adaptable fault tolerance happens
o Microservices Architecture can achieve this
o Also, for a system to be reactive it should be able to
- React to Load through scalability
- React to failure through recoverability
- React to user experience effectively
o The ability to react to events and act accordingly becomes the
main ingredient
o Leads to designing and building systems in an Event Driven
manner

38. Key take aways ...

39. Building Event Driven Systems
o What does your enterprise system look like ?
- Determine how complex or simple your system flows are
- Determine how autonomous your processing units are
- Determine how isolated your processing units should be
o What do you need to do with event processing ?
- Identify both functional as well as operational needs
o Which pattern would suit you best ?
- Select based on enterprise system characteristics and needs
o Which components do you need ?
- Identity which middleware components you need to achieve the
above

40. References
o Event Processing in Action - Opher Etzion and Peter Niblett -
Manning
o https://msdn.microsoft.com/en-us/library/dd129913.aspx
o Software Architecture Patterns - Mark Richards - Orielly
o http://radar.oreilly.com/2015/02/variations-in-event-driven-
architecture.html
o http://wso2.com/whitepapers/a-reference-architecture-for-the-
internet-of-things/
o https://www.nginx.com/blog/event-driven-data-management-
microservices/

41. CONTACT US !