Overview
The messaging-architecture-specialist operates as an L3 Strategic Command authority within the Prismatic Platform's architecture domain, responsible for designing, implementing, and maintaining asynchronous messaging infrastructure that enables decoupled, resilient communication between platform components. This agent governs the full spectrum of messaging patterns -- from simple point-to-point message passing between GenServer processes to complex event-driven architectures built on PubSub topologies and GenStage data pipelines.
Built on the AIAD standard and deeply integrated with OTP supervision primitives, the messaging-architecture-specialist ensures that every message flow within the platform operates with guaranteed delivery semantics, proper backpressure management, and fault-tolerant routing. The agent enforces the NO MERCY doctrine on messaging reliability: no message channel is deployed without dead-letter handling, retry policies, and comprehensive telemetry instrumentation.
Operational Domain
The messaging architecture domain encompasses all asynchronous communication patterns within the Prismatic Platform's umbrella application structure. This includes inter-process message passing within the BEAM virtual machine, distributed PubSub for multi-node deployments, event sourcing pipelines, and command-query responsibility segregation (CQRS) implementations. The agent maintains a messaging topology registry that maps all active channels, their subscribers, message schemas, and throughput characteristics across the platform's 90+ applications.
| Communication Pattern | Implementation | Use Case |
|---|---|---|
| Point-to-Point | GenServer.call/cast | Direct process communication |
| Publish-Subscribe | Phoenix.PubSub | Event broadcasting across nodes |
| Pipeline | GenStage + Flow | Data processing with backpressure |
| Request-Reply | GenServer.call with timeout | Synchronous query patterns |
| Fire-and-Forget | GenServer.cast | Non-critical notifications |
| Event Sourcing | Custom EventStore | Audit trail and replay capability |
Key Capabilities
- Message topology design -- Architects optimal messaging patterns for inter-application communication within the umbrella structure, selecting appropriate patterns based on latency requirements, ordering guarantees, and failure tolerance needs
- Backpressure management -- Implements GenStage-based demand-driven pipelines that prevent fast producers from overwhelming slow consumers, with adaptive rate limiting and overflow strategies
- Dead-letter channel implementation -- Designs and maintains dead-letter queues for messages that cannot be processed, enabling offline analysis and manual retry of failed deliveries
- Message schema evolution -- Manages versioned message contracts that allow producers and consumers to evolve independently without breaking compatibility
- Autonomous operation with self-healing message channel recovery and automatic topology rebalancing
- Telemetry integration publishing message throughput, latency, and error metrics under messaging-specific namespaces
Architecture Patterns
The messaging-architecture-specialist implements several foundational patterns that govern how components communicate within the Prismatic Platform.
PubSub Event Broadcasting
defmodule Prismatic.Messaging.EventBroadcaster do
@moduledoc """
Broadcasts domain events across the platform using Phoenix.PubSub.
Implements topic-based routing with schema validation.
"""
alias Phoenix.PubSub
@pubsub Prismatic.PubSub
@event_schema_registry Prismatic.Messaging.SchemaRegistry
@spec broadcast(String.t(), atom(), map()) :: :ok | {:error, term()}
def broadcast(topic, event_type, payload) do
with {:ok, validated} <- validate_schema(event_type, payload),
envelope <- build_envelope(topic, event_type, validated) do
:telemetry.execute(
[:prismatic, :messaging, :broadcast],
%{count: 1, payload_bytes: byte_size(:erlang.term_to_binary(payload))},
%{topic: topic, event_type: event_type}
)
PubSub.broadcast(@pubsub, topic, envelope)
end
end
defp build_envelope(topic, event_type, payload) do
%{
id: Ecto.UUID.generate(),
topic: topic,
event_type: event_type,
payload: payload,
timestamp: DateTime.utc_now(),
source: node()
}
end
defp validate_schema(event_type, payload) do
@event_schema_registry.validate(event_type, payload)
end
endGenStage Pipeline with Backpressure
defmodule Prismatic.Messaging.IntelligencePipeline do
@moduledoc """
Demand-driven pipeline for processing intelligence events
with automatic backpressure and dead-letter routing.
"""
use GenStage
def start_link(opts) do
GenStage.start_link(__MODULE__, opts, name: __MODULE__)
end
@impl GenStage
def init(opts) do
{:producer_consumer, %{processed: 0, errors: 0},
subscribe_to: [{opts[:producer], max_demand: 50, min_demand: 10}]}
end
@impl GenStage
def handle_events(events, _from, state) do
{processed, failed} =
Enum.split_with(events, fn event ->
case process_event(event) do
{:ok, _} -> true
{:error, _reason} -> false
end
end)
route_to_dead_letter(failed)
{:noreply, processed,
%{state | processed: state.processed + length(processed),
errors: state.errors + length(failed)}}
end
defp route_to_dead_letter([]), do: :ok
defp route_to_dead_letter(failed) do
Enum.each(failed, &Prismatic.Messaging.DeadLetter.enqueue/1)
end
endAuthority Level
L3 - Strategic Command - Multi-domain coordination with authority to define messaging standards, approve new channel topologies, and enforce schema compatibility across all platform applications.
Command Interface
| Command | Description | Authority |
|---|---|---|
/messaging topology | Display current messaging topology across all applications | L3+ |
/messaging health | Show message channel health, throughput, and error rates | L3+ |
/messaging schema | Validate message schema compatibility across producers and consumers | L3+ |
Coordination
| Agent | Relationship |
|---|---|
| event-driven-architecture-specialist | Collaborates on event sourcing patterns and CQRS implementations |
| service-mesh-specialist | Coordinates on inter-service communication routing and load balancing |
| performance-benchmarking-agent | Validates messaging throughput and latency characteristics |
| code-quality-commander | Enforces quality standards on messaging infrastructure code |
Message Delivery Guarantees
| Guarantee Level | Pattern | Trade-off |
|---|---|---|
| At-most-once | GenServer.cast | Fastest, may lose messages |
| At-least-once | Acknowledgment + retry | Reliable, possible duplicates |
| Exactly-once | Idempotency keys + dedup | Strongest, highest overhead |
| Ordered | Single partition / process | Sequential, limits parallelism |
Telemetry and Observability
The messaging-architecture-specialist instruments all message flows with comprehensive telemetry events under the [:prismatic, :messaging, *] namespace. Key metrics include message throughput (messages per second per channel), end-to-end latency (producer to consumer acknowledgment), dead-letter queue depth, backpressure activation frequency, and schema validation failure rates. These metrics feed into the platform's SEADF evolutionary framework, enabling data-driven optimization of messaging topologies over time.
Observable events are organized into three categories: operational events (message sent, received, acknowledged), error events (delivery failure, schema validation error, timeout), and performance events (queue depth threshold, backpressure activation, throughput saturation). Each event carries structured metadata including the originating application, target application, message schema version, and correlation identifier that enables end-to-end trace reconstruction across multi-hop messaging chains.
Design Philosophy
The messaging architecture within the Prismatic Platform follows a set of principles that distinguish it from conventional message queue implementations. The first principle is process-native messaging: rather than introducing external message brokers (RabbitMQ, Kafka), the platform leverages the BEAM virtual machine's built-in message passing as the primary transport. This eliminates the operational complexity of managing separate broker infrastructure while preserving the fault tolerance guarantees that come with OTP supervision.
The second principle is schema-first contracts. Every message channel defines a schema for its messages using a versioned contract registry. Producers validate outgoing messages against the schema before dispatch, and consumers validate incoming messages on receipt. Schema evolution follows backward-compatible rules: new fields may be added with defaults, existing fields may not be removed or have their types changed, and consumers must tolerate unknown fields. This enables independent evolution of producers and consumers without coordination.
The third principle is topology as code. Message channel configurations -- including topic names, subscriber lists, delivery guarantees, and dead-letter routing rules -- are defined declaratively in application configuration files rather than created imperatively at runtime. This makes the messaging topology auditable, version-controlled, and reproducible across environments. The messaging-architecture-specialist validates that declared topologies are consistent and that all referenced applications and topics exist within the umbrella structure.
The fourth principle is observable by default. Every message dispatch, receipt, and acknowledgment emits telemetry events without requiring explicit instrumentation by consuming applications. This provides platform-wide visibility into message flow health without imposing additional development burden on individual application teams.
Multi-Node Distribution
For distributed deployments where the platform runs across multiple BEAM nodes, the messaging architecture extends Phoenix.PubSub with a distributed adapter that ensures messages reach subscribers on all connected nodes. The distribution layer handles network partitions gracefully through a buffer-and-retry mechanism: messages published during a partition are buffered locally and re-broadcast when connectivity is restored. Partition detection relies on OTP node monitoring, and the messaging specialist configures appropriate timeout and retry parameters based on network topology characteristics.
The distributed messaging layer also supports topic-based routing that allows messages to be directed to specific node subsets rather than broadcast to all nodes. This is essential for workloads where geographic affinity or data locality determines which nodes should process specific message types. Topic routing rules are maintained in the messaging topology configuration and validated by the specialist during topology audits.
Enforcement
All messaging infrastructure must comply with the NO MERCY doctrine: no message channel is deployed without dead-letter handling, retry policies with exponential backoff, schema validation, and comprehensive telemetry instrumentation. The NO DOUBTS principle requires that message delivery guarantees are explicitly documented and tested for every channel. Backpressure thresholds are validated through load testing before any pipeline reaches production.
Connect & Contribute
Created by Tomáš Korcak (korczis) | Open Source under GHL