With event-driven architecture to resilient and dynamic IT solutions

Digital systems must Fast, flexible and resilient be. Traditional request-response architectures (RRA) often encounter problems: They require high availability, are highly coupled and require well-developed concepts for scalability. These limitations show where alternative architecture patterns - especially the Event Driven Architecture (EDA) - offer clear added value.

The DFA represents a paradigm shift: Events are placed at the center. Instead of direct dependencies, the following applies: "An action takes place in one system - other systems can react to it." This reduces coupling, availability requirements are eased and systems can be scaled more easily.

Challenges of classic architectures

• Strong coupling - services are directly interdependent.
• High availability requirements - If a service fails, the entire system often comes to a standstill.
• Scaling problems - Spontaneous load peaks are difficult to absorb.

How Event Driven Architecture works

Event Driven Architecture (EDA) means that systems recognize events (Events) when something relevant happens and other systems can consume these events in order to react independently. There are none direct call from the producer to the consumer - the link is established via an event broker (e.g. Kafka, SNS/SQS, RabbitMQ). This allows producers and consumers to be scaled and developed independently of each other or to be temporarily offline.

• Producercreates an event (e.g. "CustomerCreated") and publishes it in the broker.
• BrokerStores/distributes events and enables replays and scaling.
• Consumersubscribes to relevant events and executes the resulting actions.

Practical example: Customer system with EDA

The following diagram shows a typical EDA interaction. The customer frontend triggers the creation of a customer in the customer management system via an API. After successful creation, an event with the customer data (first_name, last_name, email) is placed in the event broker. Independent systems such as billing or contract management consume this event and carry out their subsequent steps - without being directly controlled by the customer management system.

AdvantageNo point-to-point dependencies, better resilience and scalable processing - consumers can catch up on events if they were offline for a short time.

The three cornerstones of event-driven architecture

The EDA is based on three fundamental principles:

Loose Coupling

• Services communicate via events.
• New consumers can be added easily and independently.
• Systems remain flexible and expandable.

Asynchronous communication

• Producers and consumers do not have to be online at the same time.
• Events are temporarily stored in queues or brokers.
• Load peaks can be processed with a time delay.

Eventual Consistency

• Data is not immediately synchronized, but synchronizes over time.
• Conscious conflict and error management is required.
• Enables high availability and scalability.

Understanding events - more than just news

A Event describes a relevant change in a system.

Examples:

• CustomerCreated -> A new customer has been created in Customer Management. Contract management then creates a new contract for the customer.
• ContractCreated -> A new contract has been created by Contract Management. The customer management system then notifies the customer that the contract has been successfully created.

Naming conventions: events vs. commands - what is the difference and why is it important?

• Event:
  • Describes something that has already happened (past). Factual state, unchangeable.
  • Is typically "broadcasted" - many consumers can read the same event.
  • Example: CustomerCreated, InvoicePaid, ContractTerminated.
• Command:
  • Requests a concrete action (imperative, future). Intention/intent of a caller.
  • Typically addresses a recipient/owner.
  • Example: CreateCustomer, SendInvoice, TerminateContract.

Why between system partners is preferred Events instead of Commands be used

• Coupling and responsibilities:
  • Commands link callers to the person responsible for the functional object. Events decouple producers from consumers.
• Data flow and scaling:
  • Events enable fan-out, replays, auditing and analytics without burdening the producer. Commands scale along the writing authority.
• Consistency model:
  • Commands change states; events document changes. Eventual consistency arises because consumers process changes with a time delay.
• Fault tolerance:
  • Consumers can catch up on events (retry/replay). With commands, the caller must deal with timeouts/errors or use an asynchronous command queue.

Advantages of EDA at a glance

• Flexibility - New consumers can be connected at any time.
• Resilience - Failures of individual systems do not jeopardize the overall system.
• Scalability - Peak loads can be handled efficiently.
• Reactivity - Systems react immediately to events. 
• Modularity - State changes are published as events and can be consumed and processed by multiple systems in a decoupled manner