electronicArtefacts Creative technology studio for complex digital systems

CONCEPT

Event-Driven Architecture

Event-driven architecture is a system design approach in which components publish, transport and react to records of state change rather than depending only on direct synchronous calls.

Event-driven architecture connects event producers, brokers or logs, consumers, schemas, delivery semantics, projections and observability.

active production

EDITORIAL FRAME

What this entry establishes.

A concise view of its scope, position, limitations and supporting sources.

Scope

Defined scope

  1. Events
  2. Producers and consumers
  3. Streams and brokers
  4. Delivery semantics
  5. Idempotency
  6. Projections

Position

Editorial position

  1. Events reduce temporal coupling but introduce ordering, duplication, replay and observability concerns.
  2. Durable event systems require explicit schemas, identifiers and consumer behavior.

Limits

Explicit limits

  1. Renaming arbitrary messages as events without recording a meaningful state change
  2. Assuming asynchronous transport removes the need for contracts and failure handling

Topics

Tags and disciplines

Event-Driven ArchitectureEvent StreamsMessagingIdempotencyProjectionsSoftware ArchitectureSystems DesignProgrammingDistributed Systems

Sources

References behind this page

  1. CloudEvents Cloud Native Computing Foundation

Definition

Event-driven architecture organizes behavior around events: durable descriptions that something happened. Producers emit events, transport infrastructure makes them available, and consumers react without requiring the producer to control every downstream action.

Architecture

An event normally needs an identifier, type, source, time, subject and data. Brokers, queues or logs manage transport. Consumers update projections, trigger workflows or integrate systems.

Electronic Artefacts position

VASTE uses event propagation as part of contextual execution. Events should retain entity identity and relation context so that downstream behavior remains explainable.

Limitations

Consumers may receive duplicates, events can arrive late or out of order, schemas evolve, and replay can reproduce unintended side effects. Idempotency, versioning and observability are core design requirements.

References

See CloudEvents, Redis Streams, Contextual Execution and Graph Runtime.

DOCUMENTED RELATIONSHIPS

Connected work and ideas.

Each link names the relationship between two entries and why it matters.

evidence

Documented by

Event-Driven Architecture and Event Streams

Event-Driven Architecture and Event Streams documents event-driven system design.

Documented by

Redis Streams for Orchestration

Redis Streams for Orchestration places Redis consumer groups within event-driven architecture.

Documented by

Microservices, Modular Monoliths and System Boundaries

Microservices, Modular Monoliths and System Boundaries explains events as one service communication pattern.

Documented by

Observability for AI Agents and Tool-Calling Systems

Observability for AI Agents and Tool-Calling Systems documents Event-Driven Architecture as one of its declared subjects.

Documented by

Runtime Engines and Domain Operating Systems

Runtime Engines and Domain Operating Systems documents Event-Driven Architecture as one of its declared subjects.

implementation

Applied by

VASTE

VASTE applies event-driven architecture through its event propagation layer.

structure

Member of collection

Knowledge Hub Third Wave

Event-Driven Architecture is an explicit member of the Knowledge Hub Third Wave collection.

Record details Metadata, sharing and citation

Reference

Cite this page

Event-Driven Architecture. 1.0.0. Electronic Artefacts, 2026-06-24. https://electronicartefacts.com/knowledge/concepts/event-driven-architecture/

Canonical URL

Related context

Nearby relationships

7 public links connect this page to nearby projects, concepts and references.