| name | architecture-paradigm-event-driven |
| description | Structure systems around asynchronous, event-based communication to decouple producers and consumers for improved scalability and resilience. Triggers: event-driven, message queue, pub/sub, asynchronous processing, event bus, real-time processing, loose coupling, event choreography, event orchestration Use when: real-time or bursty workloads (IoT, trading, logistics), multiple subsystems react to same events, system extensibility is high priority DO NOT use when: selecting from multiple paradigms - use architecture-paradigms first. DO NOT use when: simple request-response patterns suffice. DO NOT use when: strong ordering guarantees are critical without careful design. Consult this skill when designing event-driven systems or implementing messaging patterns. |
| version | 1.0.0 |
| category | architectural-pattern |
| tags | architecture, event-driven, asynchronous, decoupling, scalability, resilience |
| dependencies | |
| tools | message-broker, event-stream-processor, distributed-tracing |
| usage_patterns | paradigm-implementation, real-time-processing, system-extensibility |
| complexity | high |
| estimated_tokens | 800 |
The Event-Driven Architecture Paradigm
When to Employ This Paradigm
- For real-time or bursty workloads (e.g., IoT, financial trading, logistics) where loose coupling and asynchronous processing are beneficial.
- When multiple, distinct subsystems must react to the same business or domain events.
- When system extensibility is a high priority, allowing new components to be added without modifying existing services.
Adoption Steps
- Model the Events: Define canonical event schemas, establish a clear versioning strategy, and assign ownership for each event type.
- Select the Right Topology: For each data flow, make a deliberate choice between choreography (e.g., a simple pub/sub model) and orchestration (e.g., a central controller or saga orchestrator).
- Engineer the Event Platform: Choose the appropriate event brokers or message meshes. Configure critical parameters such as message ordering, topic partitions, and data retention policies.
- Plan for Failure Handling: Implement robust mechanisms for handling message failures, including Dead-Letter Queues (DLQs), automated retry logic, idempotent consumers, and tools for replaying events.
- Instrument for Observability: Implement comprehensive monitoring to track key metrics such as consumer lag, message throughput, schema validation failures, and the health of individual consumer applications.
Key Deliverables
- An Architecture Decision Record (ADR) that documents the event taxonomy, the chosen broker technology, and the governance policies (e.g., for naming, versioning, and retention).
- A centralized schema repository with automated CI validation and consumer-driven contract tests.
- Operational dashboards for monitoring system-wide throughput, consumer lag, and DLQ depth.
Risks & Mitigations
- Hidden Coupling through Events:
- Mitigation: Consumers may implicitly depend on undocumented event semantics or data fields. Publish a formal event catalog or schema registry and use linting tools to enforce event structure.
- Operational Complexity and "Noise":
- Mitigation: Without strong observability, diagnosing failed or "stuck" consumers is extremely difficult. Enforce the use of distributed tracing and standardized alerting across all event-driven components.
- "Event Storming" Analysis Paralysis:
- Mitigation: While event storming workshops are valuable, they can become unproductive if not properly managed. Keep modeling sessions time-boxed and focused on high-value business contexts first.