Motivation
Enterprise AI systems receive events from many sources: structured UI selections, API calls, document uploads, free-text messages. Some carry a clear signal — the user selected "Report a Claim." Others are ambiguous — the user typed "I need help with something."
The naive approach embeds classification logic inside the router. This couples routing and classification, and when the classification strategy changes (rules → LLM → NLP), the router changes too. The Event Router Pattern solves this by making the Router the single, dumb entry point and delegating classification to a separate, Kafka-decoupled IntentOrchestrator.
Three Routing Outcomes
- Deterministic — event_type is in the routing table. Router publishes directly to the domain topic. No LLM, zero latency.
- Non-deterministic, resolved — event_type unknown. Router publishes to intent.in. IntentOrchestrator classifies and re-publishes to the domain topic.
- Clarification required — intent cannot be determined with sufficient confidence. IntentOrchestrator publishes a "please clarify" response. Nothing is silently dropped.
Key Principle
The Router is always the single entry point. The IntentOrchestrator is a Kafka-decoupled process — it consumes intent.in independently. The Router does not know it exists. This follows the same topology used throughout K9-AIF: Router publishes, Orchestrators consume.
EIP Lineage
- Content-Based Router (Hohpe & Woolf) — IntentOrchestrator classifies and re-routes based on message content
- Message Channel — intent.in and responses.out are typed Kafka channels
- Pipes and Filters — Router → intent.in → IntentOrchestrator → domain topic