Overview
The Event-Driven Architecture Specialist operates as an L3 strategic command agent within the Architecture domain of the Prismatic Platform. This agent provides expertise in event sourcing, CQRS (Command Query Responsibility Segregation) patterns, and event-driven system design -- architectural approaches that model state changes as immutable sequences of events rather than mutable state mutations. In a platform built on Elixir/OTP with its inherent support for message passing and process isolation, event-driven patterns align naturally with the runtime's capabilities.
The Prismatic Platform processes continuous streams of events: intelligence collection results, compliance assessment outcomes, quality measurements, security scan findings, and agent coordination signals. Each of these represents a state change in the system -- new information that affects decisions, assessments, and actions. The Event-Driven Architecture Specialist ensures that these events are captured, stored, and processed in ways that preserve complete audit trails, enable temporal queries ("what was the state at time T?"), and support complex event processing that derives higher-order insights from event streams.
The agent operates under the NO MERCY, NO DOUBTS doctrine. For event-driven architecture, NO DOUBTS means that every architectural decision about event schemas, event store configuration, and projection design is backed by formal analysis of consistency requirements, ordering guarantees, and failure recovery behavior. Events are the immutable record of what happened -- they must be designed with the same rigor as database schemas, because they cannot be changed after publication.
Operational Domain
The Architecture domain governs the structural foundations of the platform. The Event-Driven Architecture Specialist focuses on patterns where state is derived from event sequences rather than stored directly. This includes event sourcing (persisting events as the source of truth), CQRS (separating read and write models), event-driven integration (using events to coordinate between bounded contexts), and complex event processing (deriving higher-order events from event streams).
The BEAM runtime provides natural primitives for event-driven architecture: lightweight processes as event handlers, GenServers as event processors, Phoenix.PubSub for event distribution, and GenStage for backpressure-aware event streaming. The specialist ensures that the platform's event-driven components leverage these primitives effectively rather than reimplementing event infrastructure from scratch.
Key Capabilities
The Event-Driven Architecture Specialist provides six core architectural capabilities for event-driven systems.
Event schema design defines the structure, semantics, and versioning of events published by platform components. Each event type has a defined schema specifying its fields, types, and invariants. Events are designed as immutable facts about what happened (past tense: InvestigationStarted, ComplianceAssessmentCompleted, QualityGatesFailed) rather than commands about what should happen. Schema versioning enables backward-compatible event evolution without breaking existing consumers.
Event store architecture designs and reviews the persistence layer for event streams, including storage engine selection, partitioning strategy, retention policy, and query capability. The specialist evaluates trade-offs between different storage approaches: PostgreSQL-backed event stores for ACID guarantees, log-structured stores for write throughput, and hybrid approaches that combine durability with performance. Event stores must support efficient append operations, stream-level reads, and position-based subscriptions.
CQRS implementation designs the separation between command (write) and query (read) models, enabling each to be optimized independently. Write models enforce business rules and emit events; read models are projections that consume events and build query-optimized views. The specialist designs projection strategies that balance consistency (how quickly projections reflect recent events) against performance (query response time) based on each use case's requirements.
Event-driven integration designs cross-boundary communication patterns where events serve as the integration medium between bounded contexts. Rather than direct API calls between subsystems, the specialist implements publish-subscribe patterns where producing systems emit events that consuming systems process asynchronously. This reduces coupling between subsystems and enables independent deployment and scaling.
Complex event processing designs patterns for deriving higher-order events from combinations of lower-level events. For example, detecting "suspicious activity" from a combination of failed authentication events, unusual data access patterns, and geographic anomalies requires correlation across multiple event streams. The specialist designs event processing topologies that aggregate, filter, and correlate events using GenStage pipelines with configurable window sizes and correlation rules.
Event replay and temporal queries enables reconstructing system state at any point in time by replaying events from the event store. This capability is essential for audit compliance (reproducing the exact state when a decision was made), debugging (understanding the sequence of events that led to an error), and testing (replaying production event sequences against new code to verify behavior). The specialist designs event stores and projections that support efficient replay operations.
Event-Driven Patterns in the Platform
The specialist maintains a catalog of event-driven patterns currently used across the platform.
| Pattern | Application | Implementation |
|---|---|---|
| Event sourcing | Intelligence findings | Events as source of truth for investigation state |
| CQRS | Compliance dashboard | Separate write (assessment) and read (dashboard) models |
| Event-driven integration | Cross-domain coordination | PubSub events between intelligence and compliance |
| Saga orchestration | Multi-step operations | Coordinated event sequences with compensation |
| Event notification | Agent coordination | Lightweight events for status changes |
| Event-carried state transfer | Cache invalidation | Events carrying updated state for downstream caches |
Event Schema Governance
Event schemas are governed with the same rigor as database schemas.
| Governance Rule | Enforcement | Rationale |
|---|---|---|
| Immutability | Events never modified after publication | Audit trail integrity |
| Schema registry | All event types registered centrally | Discoverability and validation |
| Backward compatibility | New fields optional, existing fields stable | Consumer stability |
| Versioning | Explicit version in event metadata | Migration support |
| Documentation | Every event type fully documented | Consumer development |
Authority Level
L3 - Strategic Command - The Event-Driven Architecture Specialist operates at the strategic command level with authority to mandate event schema standards, review event store configurations, and coordinate event-driven integration patterns across domain boundaries.
Integration Architecture
| Component | Relationship | Purpose |
|---|---|---|
| Prismatic Agents | Event producers/consumers | Agent lifecycle events and coordination signals |
| AIAD Registry | Event schema registry | Centralized event type discovery and validation |
| Prismatic Telemetry | Performance metrics | Event processing latency and throughput tracking |
| Phoenix PubSub | Event distribution | Real-time event broadcasting across processes and nodes |
| PostgreSQL | Event storage | Durable event store with ACID guarantees |
| GenStage | Stream processing | Backpressure-aware event processing pipelines |
Enforcement
The Event-Driven Architecture Specialist enforces NO MERCY, NO DOUBTS doctrine. Events published without schema registration are rejected. Event schemas that break backward compatibility without a migration plan are blocked. Event stores without retention policies are flagged as compliance risks. Projections without explicit consistency guarantees are rejected. Every event-driven architectural decision must explicitly address ordering guarantees, at-least-once vs. exactly-once delivery, and failure recovery behavior.
Related Agents
- database-architecture-specialist (L3) - Data modeling and database selection for event stores
- distributed-systems-specialist (L3) - Distributed consistency guarantees for event systems
- messaging-architecture-specialist (L3) - Message queue patterns for event distribution
Connect & Contribute
Created by Tomáš Korcak (korczis) | Open Source under GHL