Event Driven Architecture

Event-Driven Architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events. An event can be defined as a significant change in state, and this architecture revolves around the idea of responding to these actions or changes. EDA is widely used because it allows for high responsiveness, flexibility, and scalability in applications.

1. Fire and Forget: User activity data sent to a logging service, no response required.
2. Reliable Delivery: E-commerce applications retry until orders are processed.
3. Infinite Stream of Events: Twitter processes endless stream of tweets.
4. Anomaly Detection/Pattern Recognition: Real-time fraud detection in credit card transactions.
5. Broadcasting: Stock price changes broadcasted to subscribed traders.
6. Buffering: Netflix loads video chunks for uninterrupted playback.

 

	Description	Example
Event Streaming	This pattern involves a continuous, real-time flow of events that are produced and immediately processed. There is no explicit subscription needed as all events are available to be processed	A music streaming app like Spotify uses event streaming. When a user plays a song, the data (song) is streamed or sent continuously allowing the user to listen to it in real time
Publisher/Subscriber	This pattern involves publishers producing events and subscribers actively choosing which events they want to listen to and react to. It allows for a decoupling of the event source from its consumers	A blog website can use this pattern. When a blogger (publisher) posts a new blog, only the users (subscribers) who have subscribed to that particular blogger or topic will be notified.

 

Saga Design Pattern

• The Saga design pattern is used to manage transactions that span multiple services in a microservices architecture.
• It maintains data consistency across services with a series of local transactions.
• Example: In an e-commerce app, placing an order may involve multiple services such as inventory, payment, and shipping. The Saga pattern ensures that either all these operations succeed, or, if one fails, appropriate compensating transactions are executed.

  

	Orchestration	Message Broker
Description	Orchestration involves a central controller (orchestrator) that dictates how the services will interact with one another.	A message broker pattern uses a communication platform for services to send messages between each other.
Key Point	Provides centralized control and is simple to understand, but can create a bottleneck.	Decouples services and allows asynchronous communication, but adds complexity and requires careful handling of message delivery.

Command Query Responsibility Segregation (CQRS)

This pattern separates read and write operations for improved performance and scalability.

Use Case 1: Separate Read and Write

Separate Read and Write in an ecommerce system, frequent read operations like browsing products can be optimized separately from less frequent write operations like inventory updates. 

Use Case 2: Materialized View

Materialized View, combining data from multiple microservice to create a joined view

 

Event Sourcing

• Event Sourcing is a design pattern that ensures all changes to application state are stored as a sequence of events. These events can be queried, and the state can be reconstructed at any point of time.
• It's useful in systems where complete history of actions is necessary, like in banking transactions where all transactions are recorded and can be used to trace the current balance.

Contract Testing

• Contract testing verifies microservices interaction using expected requests and responses.
• It makes issue detection easier without full integration.
• It allows independent development and scaling of microservices
• Pact is a tool that can be used for contract testing