PATTERN Cited by 1 source

Inbound / outbound topic pairing¶

Pattern¶

Split Kafka topics along the direction of data flow relative to the processing system, not just along subject matter:

Inbound topics carry what the system needs to react to — external requests, vendor responses, upstream events.
Outbound topics carry what the system produces — decisions, alerts, escalations, enriched events for downstream consumers.

The separation is load-bearing, not cosmetic: it gives the system clean retry + replay semantics, prevents accidental write-feedback loops, and lets inbound and outbound scale independently.

Canonical disclosure: IBM + AWS KYC architecture. "The streaming infrastructure organizes into distinct topic categories supporting bi-directional flows. Inbound topics capture customer interactions ... Outbound topics publish KYC decisions with confidence scores and audit trails to core banking systems..." (Source: sources/2026-04-23-aws-modernizing-kyc-with-aws-serverless-solutions-and-agentic-ai.)

Canonical shape from the KYC architecture¶

Inbound (four categories):

Category	Example payloads
KYC requests	New customer application submission
Document uploads	Identity docs, proof of address
ID verification results	Third-party vendor responses
Transaction events	Fraud / risk signals tied to an existing customer

Event listeners sit on the inbound side, pre-processing before the main agent runtime sees the data: - Filter onboarding requests. - Prepare documents for OCR. - Normalise vendor data formats. - Correlate transaction signals with customer profiles.

Outbound (three categories):

Category	Destination
KYC decisions (with confidence + audit trail)	Core Banking
Case-management events (escalated complex cases)	Human reviewer queue
Fraud alerts	Security teams

The inbound categories are many-to-many with outbound categories — a single customer onboarding request may trigger a decision and a fraud alert and a case-management event.

Why pairing matters¶

Three specific failure modes inbound-only topic design has, that pairing avoids:

Feedback loops. If agents write outputs back onto the same inbound topic (or a shared topic), a downstream replay / retry can re-trigger processing. Separate outbound topics make the data-flow direction explicit and one-way.
Mixed retention / compaction policies. Inbound topics often want short retention (process-and-forget); outbound topics want long retention (audit, replay downstream). Separating them lets each side pick its own retention + compaction policy.
Mixed security boundaries. Inbound topics may carry raw PII (identity documents); outbound topics carry decisions + audit metadata. Different encryption, access policies, and retention compliance apply. Separate topics make those boundaries enforceable.

Diagram¶

external systems ──► ┌────────────────┐
(customers, vendors) │ Inbound topics │ ──► event listeners ──► agent runtime
                     │  (kyc-requests,│                                │
                     │  doc-uploads,  │                                │
                     │  vendor-resp,  │                                │
                     │  tx-events)    │                                ▼
                     └────────────────┘                      ┌───────────────┐
                                                             │Outbound topics│
                                                             │ (decisions,   │
                                                             │  escalations, │
                                                             │  fraud-alerts)│
                                                             └───────┬───────┘
                                                                     │
                                                                     ▼
                                                        downstream systems
                                                      (core banking, case mgmt,
                                                       security teams)

When to reach for it¶

Any event-driven orchestration system that both consumes and produces Kafka events.
Cases where retention policies differ between request traffic and decision / result traffic.
Cases where replay semantics matter — you want to replay outbound events for downstream catch-up without re-triggering agent processing.

Anti-patterns¶

Single mega-topic — one topic for both requests and decisions. Every consumer has to filter on event type; retention is a single compromise between the two classes; replay risks double-processing.
Outbound-as-side-effect. Writing outbound events as a side effect of consuming inbound events without a clean topic separation means retry + replay re-generate side effects non-idempotently.
Collapsing categories within outbound. If decisions + fraud alerts + escalations all go to one topic, downstream systems have to filter. Three separate topics let Core Banking, Case Management, and Security scale + retry independently.

Relation to other patterns¶

Multi-agent streaming coordination (patterns/multi-agent-streaming-coordination): agents coordinate on Kafka topics. Inbound/outbound pairing is the topology that multi-agent streaming uses at the system boundary.
Async agent invocation over Kafka (patterns/async-agent-invocation-over-kafka): describes the single-direction MSK → Lambda → agent boundary. Pairing describes the whole topic topology (both sides).

Seen in¶

sources/2026-04-23-aws-modernizing-kyc-with-aws-serverless-solutions-and-agentic-ai — four inbound topic categories + three outbound topic categories + an event-listener pre-processing stage on the inbound side.