Event-Driven Applications

The basis of event-driven applications, will cover the following topics:

➢ Understanding modern applications
➢ Evolution of integration patterns
➢ Automation with serverless
Event-Driven Applications
Understanding modern applications:
The shift to serverless technologies has introduced a new approach in cloud computing:
event-driven architectures. These architectures are based on two main factors:
1.Event Sourcing: This is the method of storing state changes in real-time.
2.Stream Processing: This involves consuming these changes for further computation or
storage.
Many AWS serverless services are inherently event-driven, making them highly scalable
and resilient. This combination is ideal for building distributed systems in the cloud.
Event-Driven Applications
Event-Command Simplified
➢ In the past, we used large, all-in-one systems (monoliths). Now, we use smaller,
independent services (microservices). This allows us to update parts of the system
separately and avoid complex dependencies that make updates difficult.
➢ However, simply splitting into microservices isn't enough if we still need to manage
everything centrally. If our microservices depend too much on each other, we might
end up with the same problems as before.
Event-Driven Applications
Request-Driven Approach
➢ Tightly coupled microservices can lead to lots of dependencies, which might make
things as complicated as a monolithic architecture.
Challenges:
➢ High Dependency
➢ Reduced Modularity
➢ Single Point of Failure
➢ Complex Deployment
Event-Driven Applications
Request-Driven Approach
➢ In a request-driven approach, one service asks another to do something based on an
event. This can be synchronous (waiting for a response) or asynchronous (not
waiting). This approach is known as event-command.
Event-Driven Applications
To explain this simply, let's look at how RESTful APIs work for microservices.
➢ Imagine we have a service that creates new customer accounts for an online store.
When a request to create an account comes in, this service needs to contact several
other services. These might include:
1.Fraud Service - Checks if the request is legitimate.
2.Email Service - Sets up and verifies the customer's email address.
3.User Profile Service - Creates new entries in the ERP and CMS systems.
Event-Driven Applications
➢ These services are loosely coupled, meaning they can be updated and managed
independently
with their own data.
➢ However, the main service (that creates accounts) still needs to know how to communicate
with and request actions from these other services. This setup creates dependencies at multiple
levels.
Event-Driven Applications
Challenges:
➢ Should the service wait for a response or handle timeouts gracefully?
➢ How does it keep track of changes in other services' interfaces?
➢ How can it roll back changes if something goes wrong?
➢ Can it use a circuit breaker to stop a chain of failures?
Event-Driven Applications
Goal:
➢ We want modular services with APIs that separate responsibilities and reduce dependencies,
making them more real-time.
➢ Instead of coordinating actions, services should react only to events they care about.
Evolution of Integration Patterns
➢ Integration is the process of enabling data communication between multiple systems.
There are many ways to do this, and these methods have evolved with technology.
1. Enterprise Application Integration
2. ESB
3. Serverless Integration
Evolution of Integration Patterns
Enterprise Application Integration.
➢ Enterprise Application Integration (EAI) is about making it easier for different systems
in a business to share data.
➢ For example, a retail store might use a CRM system, a supply chain system, and a
payment system.
➢ All these systems need to share information, like a customer's contact details from the
CRM, so the invoicing system can create accurate invoices. EAI helps these systems
communicate efficiently with each other.
Evolution of Integration Patterns
➢ In the past, EAI was the best way to share information between systems.
➢ It involved creating a central integration application that all other applications
connected to for data exchange.
➢ Adding a new application was easy because it only needed to connect to this
central app.
➢ While this approach was effective for data sharing, it had limitations before
 serverless technologies came along.
Evolution of Integration Patterns
➢ In the early days, integration applications were hosted on a single server.
➢ All systems connected to this one server for data exchange.
➢ The problem was, if the server failed, all systems would be affected.
➢ Despite this, EAI enabled efficient communication between systems using event-
driven flows.
Evolution of Integration Patterns
Enterprise Service Bus (ESB).
➢ An Enterprise Service Bus (ESB) is a modern way to achieve system-to-system
communication, building on the EAI concept.
➢ Unlike EAI, ESBs are made up of smaller components that work together to create a
single bus for interactions between systems.
➢ ESBs use Service Oriented Architecture (SOA) patterns to establish a common and
standardized way of sharing data.
Evolution of Integration Patterns
➢ The main advantage of using an ESB for integration is that it simplifies connecting
new systems, requiring only configuration and minimal coding.
For example:
4. System A produces events on the ESB using Java and SOAP.
5. System B consumes these events with a .NET client using REST.
6. If System C wants to consume events using a .NET client and REST, we can easily
configure it to use the existing components in the ESB.
➢ Over time, we can build a library of connectors, making it easier and more flexible to
integrate different systems and reducing the overall effort required.
Evolution of Integration Patterns
Evolution of Integration Patterns
➢ One downside of using ESBs is that they are always running, even when idle, waiting
for messages. They require large, powerful infrastructure to avoid bottlenecks and
handle peak loads. This can be inefficient, especially if message traffic is low or
irregular.
➢ For example, if a new system (System D) using a .NET client and SOAP produces
more data than the existing Java client using SOAP, the Java component remains idle
while the .NET component handles most of the load. This shows the inefficiency of a
modular application that cannot be deployed separately.
Evolution of Integration Patterns
Serverless Integration
➢ Serverless integration is the next step in enterprise application integration.
➢ It builds on the lessons learned from EAI and ESB models and uses serverless
technologies to implement these integration patterns.
➢ We observed that not all integration components are used equally.
➢ Some connectors or transformations are used more frequently, and their usage changes
as systems evolve.
➢ Therefore, we need a model similar to microservices—something modular that can
scale independently.
 Evolution of Integration Patterns
➢ Let's consider the previous example. In a serverless setup, we could have a separate
Lambda function for each client, completely decoupling the ESB's internal workings.
➢ Instead of spreading components across multiple distributed containers, we can now
create smaller components that specifically interact with consumers or producers.
Evolution of Integration Patterns
➢ Components can now be built smaller and are only triggered by an event.
➢ For example, System A using a Java SOAP-based client that creates events
infrequently would traditionally require a SOAP component to always be running.
➢ With serverless technologies like AWS Lambda, the function only runs when an
event occurs.
➢ This makes the integration more efficient and cost-effective because you only pay
for the compute power used, not for idle time.
Evolution of Integration Patterns
➢ Now, let's take this one step further. Previously, an ESB would have had many
different
➢ components and used various different methods to transport messages or events
internally
➢ within the ESB to other components; it would then have passed these on to the
consumers.
➢ This often required a message brokering system alongside the ESB.
➢ Now, with serverless services, message brokering systems are also serverless,
eliminating the need to host and manage them yourself. This reduces overhead and
increases efficiency. cover all the points
Here is a comprehensive explanation of the key points related to Event-Driven Applications and
the Evolution of Integration Patterns based on the provided document: [1]

Event-Driven Applications

Understanding Modern Applications

Modern cloud computing has shifted towards event-driven architectures, particularly with
the rise of serverless technologies.
Event-driven architectures focus on:
1. Event Sourcing: Capturing and storing real-time state changes as a sequence of
events.
2. Stream Processing: Consuming event streams to perform computations or persist data.
Many AWS serverless services are inherently event-driven, enabling highly scalable and
resilient distributed systems in the cloud.
Event-Command Simplified
Historically, applications were monoliths (large, all-in-one systems).
Now, modern apps often use microservices: smaller, independent services that can be
updated separately.
However, merely dividing into microservices does not eliminate all complexity if services
remain tightly connected.

Request-Driven Approach Challenges

In request-driven architectures, services invoke other services either synchronously
(waiting for responses) or asynchronously.
This approach can lead to:
High dependency between services.
Reduced modularity.
Single points of failure.
Complex deployment and maintenance.

Example: RESTful API Microservices

Consider an online store account creation service that needs to:
1. Check requests via a Fraud Service.
2. Verify email through an Email Service.
3. Set up user profile data in ERP and CMS systems.
While these microservices are loosely coupled and independently managed, the main
service still depends on coordinating calls, creating multi-level dependencies.

Challenges in Request-Driven Architectures

Handling timeouts and waiting for responses gracefully.
Managing interface changes of dependent services.
Rolling back transactions or compensating for failures.
Implementing fault tolerance mechanisms like circuit breakers.

Goal of Event-Driven Applications

Create modular services with clear APIs that reduce dependencies.
Services act on events they care about instead of orchestrating complex interactions.
This approach enhances real-time responsiveness and system resilience.
Evolution of Integration Patterns

Enterprise Application Integration (EAI)

EAI focused on enabling communication among diverse business systems.
For instance, retail systems like CRM, supply chain, and payment platforms exchange
required data (e.g., customer info) through a centralized integration app.
Adding new systems was relatively straightforward by connecting to the central app.
Limitations included:
Hosting integration on a single server, leading to risk of system-wide failure if that server
went down.
Less flexibility prior to serverless advancements.

Enterprise Service Bus (ESB)

ESB advances the EAI approach by using a modular, bus-like architecture for system
interactions.
ESBs utilize Service-Oriented Architecture (SOA) for standardized data sharing.
Benefits include:
Simplified connection of new systems with minimal coding.
Example: Events produced in Java/SOAP clients can be consumed by .NET/REST
clients.
Over time, growing a library of connectors eases and accelerates integration efforts.

Limitations of ESB
ESBs require continuous operation, consuming large infrastructure resources to avoid
bottlenecks.
This can be inefficient for systems with irregular or low message traffic.
Unequal load distribution can leave some components idle while others are overloaded.
Modular deployment challenges can hinder efficiency.

Serverless Integration
Serverless integration builds on lessons from EAI and ESB, implementing patterns with
serverless technologies.
Observations include:
Integration components are unevenly used, and usage changes over time.
Hence, a microservices-like modular model is needed, with independent scaling.
Example:
Each client can have a dedicated Lambda function, decoupling internal ESB processes.
 Smaller components triggered only upon specific events, improving efficiency and
reducing idle running costs.
This model eliminates the traditional need for always-on components, leading to more cost-
effective and scalable integrations.

Advancement with Serverless Services

Traditionally, ESBs required extra message brokering systems.
Serverless services provide serverless message brokering, removing the need for self-
hosting these intermediaries.
This reduces management overhead and increases operational efficiency.

This comprehensive coverage illustrates how modern event-driven architectures and serverless
technologies transform integration from centralized and resource-heavy models to modular,
scalable, and event-based systems, enhancing flexibility and cost efficiency in cloud-based
applications. [1]
⁂

1. UNIT-1-UNIT-II-UNIT-III-SC-Master-File.pdf