Enterprise AI Platforms

AI Inside an Event-Driven Integration Platform

Enrich at-least-once events with AI while preserving schemas, idempotent business effects, bounded retries and human review.

Reference architecture - illustrative, not a client deployment

Follow an event through enrichment without duplicating the business action.

Complexity
Advanced
Drawing
Supplied
  • Event-Driven Architecture
  • AI Enrichment
  • Idempotency
  • Integration

Overview

This reference architecture is illustrative. It is not a record of a client deployment.

Adding AI enrichment to an event pipeline does not change distributed-system fundamentals. A producer commits its business transaction and outbox record together; a relay publishes the event to a broker. With at-least-once delivery, the consumer must expect duplicates. Schema checks, a stable event identifier and an idempotency record prevent a known event from creating another business effect.

Only a valid new event reaches the model. The AI returns structured enrichment, which deterministic code validates for schema, allowed values and authorization. Uncertain results go to human review. The downstream action uses an idempotency key at the effect boundary, and its observed outcome is recorded with a correlation identifier.

A concrete example

An order event is enriched with a proposed routing category. The model returns a category and confidence evidence; validation rejects unknown values and sends ambiguity to review. A network timeout occurs after the downstream system may have accepted the action. The retry handler first reconciles the recorded idempotency key. Redelivery then records the already known outcome instead of creating a second shipment.

Common misconception

"Broker deduplication gives exactly-once business actions." Duplicate detection reduces repeated messages within its configured scope. It cannot prove that an external side effect happened only once after an ambiguous timeout. The action boundary must be idempotent and reconcilable.

Diagram & Walkthrough

Choose a declared scenario and step, or select a component by pointer, touch or keyboard. Playback starts only when you press Play and pauses when this panel leaves the screen.

100%
AI Inside an Event-Driven Integration Platform An outbox event moves through at-least-once delivery, schema and idempotency checks, AI enrichment, deterministic validation and an idempotent action boundary. Ambiguous outcomes are reconciled before bounded retry, while duplicates do not trigger another business action. AI Inside an Event-Driven Integration Platform Follow an event through enrichment without duplicating the business action. RELIABLE EVENT INPUT ENRICHMENT + VALIDATION BUSINESS EFFECTS Outbox event At-least-oncedelivery Validated new event Structured enrichment Validated authorized action Uncertain result Approved action Idempotent outcome Known duplicate;no new action Ambiguous orfailed outcome Reconciled safe retry · same correlation + idempotency key Exhausted retries;inspect Business transaction+ outbox ATOMIC PUBLISH INTENT Event broker DATA Schema + idempotencychecks DETERMINISTIC AI enrichment MODEL · PROPOSAL ONLY Deterministic outputvalidation SCHEMA + POLICY Uncertain-case review HUMAN Idempotent downstreamaction IDEMPOTENCY KEY AT BOUNDARY Outcome + correlationledger DATA Bounded retries +dead-letter queue RECONCILE BEFORE RETRY DELIVERY GUARANTEE At-least-once transport + deduplication + idempotent effects; never a blanket exactly-once claim. Main data Control Feedback Failure / escalation Ambiguous writes are reconciled before retry; exhausted retries escalate instead of looping forever.

Main walkthrough, step 1 of 6: Commit and publish reliably. idle.

Main walkthrough

The primary path through this reference architecture.

Active parts: Business transaction + outbox, Event broker

Text walkthrough

This vertical reference remains readable without the interactive controls.

  1. 01Commit and publish reliably

    Commit the business state and outbox record together, then relay the durable event to the broker.

    Active parts: Business transaction + outbox, Event broker

  2. 02Validate and identify the event

    Receive under the broker's delivery model, validate the schema and check the stable event ID.

    Active parts: Event broker, Schema + idempotency checks

  3. 03Enrich with a model

    Send only a valid new event for AI enrichment, then pass its structured output to deterministic validation.

    Active parts: Schema + idempotency checks, AI enrichment, Deterministic output validation

  4. 04Validate or escalate the result

    Execute a valid authorized action or send uncertainty to a reviewer before approval.

    Active parts: Deterministic output validation, Uncertain-case review, Idempotent downstream action

  5. 05Record an idempotent business outcome

    Persist the observed result and correlation identifiers so a replay can find the existing outcome.

    Active parts: Idempotent downstream action, Outcome + correlation ledger

  6. 06Reconcile retries and duplicates

    Reconcile ambiguous effects before a bounded retry, suppress known duplicates and send exhausted cases to review.

    Active parts: Idempotent downstream action, Bounded retries + dead-letter queue, Event broker, Schema + idempotency checks, Outcome + correlation ledger, Uncertain-case review

Connections

  • Outbox eventBusiness transaction + outbox to Event brokerdata
  • At-least-once deliveryEvent broker to Schema + idempotency checksdata
  • Validated new eventSchema + idempotency checks to AI enrichmentdata
  • Structured enrichmentAI enrichment to Deterministic output validationdata
  • Validated authorized actionDeterministic output validation to Idempotent downstream actioncontrol
  • Uncertain resultDeterministic output validation to Uncertain-case reviewcontrol
  • Approved actionUncertain-case review to Idempotent downstream actioncontrol
  • Idempotent outcomeIdempotent downstream action to Outcome + correlation ledgerfeedback
  • Known duplicate; no new actionSchema + idempotency checks to Outcome + correlation ledgercontrol
  • Ambiguous or failed outcomeIdempotent downstream action to Bounded retries + dead-letter queuecontrol
  • Reconciled safe retryBounded retries + dead-letter queue to Event brokercontrol
  • Exhausted retries; inspectBounded retries + dead-letter queue to Uncertain-case reviewcontrol

Components

Business transaction + outboxexternal

Commits the business change and its event record atomically within the producer's transactional boundary.

Responsibilities

  • Create a stable event ID and preserve state-event consistency

Inputs

  • Business command
  • Transaction context

Outputs

  • Committed business state
  • Outbox event

Risks

  • Unreliable dual writes
  • Event schema drift
Event brokerdata

Durably transports events to consumers with an explicit delivery and retry model.

Responsibilities

  • Deliver events and retain correlation metadata

Inputs

  • Outbox event
  • Retry event

Outputs

  • At-least-once delivery

Risks

  • Duplicate delivery
  • Backlog and ordering changes
Schema + idempotency checksdeterministic

Validates the event contract and checks a stable identifier before enrichment begins.

Responsibilities

  • Reject invalid events and prevent known duplicates from creating new effects

Inputs

  • Delivered event
  • Schema version
  • Idempotency ledger

Outputs

  • Validated new event
  • Known-duplicate decision

Risks

  • Expiring keys too early
  • Non-backward-compatible schemas
AI enrichmentmodel

Adds a bounded classification, extraction or recommendation without directly performing the business action.

Responsibilities

  • Return the requested enrichment in the defined structured contract

Inputs

  • Validated new event
  • Versioned instructions

Outputs

  • Structured enrichment

Risks

  • Nondeterministic replay
  • Unsupported or malformed values
Deterministic output validationdeterministic

Checks model output schema, allowed values, confidence policy and action authorization.

Responsibilities

  • Approve a bounded action or escalate uncertainty

Inputs

  • Structured enrichment
  • Validation and authorization rules

Outputs

  • Validated authorized action
  • Uncertain result

Risks

  • Validation that checks shape but not meaning
  • Overconfident thresholds
Uncertain-case reviewhuman

Reviews ambiguous enrichments and exhausted retries with the evidence needed for a bounded decision.

Responsibilities

  • Approve, correct or reject an action and resolve dead letters

Inputs

  • Uncertain result
  • Dead-letter context

Outputs

  • Approved action
  • Resolution decision

Risks

  • Review backlog
  • Inconsistent decisions
Idempotent downstream actionexternal

Performs the authorized business effect under a stable idempotency key and exposes the observed outcome.

Responsibilities

  • Ensure replay does not duplicate the business effect

Inputs

  • Validated or approved action
  • Idempotency key

Outputs

  • Observed business outcome
  • Failure or ambiguous result

Risks

  • Target lacks idempotency support
  • Timeout after successful write
Outcome + correlation ledgerdata

Records event, model, decision, action and outcome identifiers for deduplication and reconciliation.

Responsibilities

  • Preserve idempotent outcome and end-to-end correlation

Inputs

  • Action outcome
  • Known-duplicate decision
  • Correlation metadata

Outputs

  • Reconciliation and audit record

Risks

  • Ledger inconsistency
  • Sensitive payload retention
Bounded retries + dead-letter queuedeterministic

Reconciles ambiguous outcomes, schedules limited safe retries and diverts exhausted cases for inspection.

Responsibilities

  • Prevent infinite loops and retry only after idempotency reconciliation

Inputs

  • Failure or ambiguous outcome
  • Retry policy
  • Correlation ledger

Outputs

  • Reconciled safe retry
  • Dead-letter case

Risks

  • Retry storms
  • Repeating an irreversible effect

Scenario reference

Duplicate delivery

Do not produce a duplicate downstream business action.

  1. 01Record the known duplicate

    The broker redelivers an event whose stable identifier is already known, so the consumer records it without another action.

    Active parts: Event broker, Schema + idempotency checks, Outcome + correlation ledger

Action failed or timed out

Reconcile ambiguous writes and enforce idempotency before retrying.

  1. 01Retry without duplicating the effect

    A validated action has an ambiguous outcome; reconciliation schedules a safe retry whose redelivery is checked against the idempotency record.

    Active parts: Deterministic output validation, Idempotent downstream action, Bounded retries + dead-letter queue, Event broker, Schema + idempotency checks, Outcome + correlation ledger

Retries exhausted

Escalate safely instead of looping forever.

  1. 01Move the case to human inspection

    After the bounded retry policy is exhausted, the correlated failure enters the dead-letter review path.

    Active parts: Idempotent downstream action, Bounded retries + dead-letter queue, Uncertain-case review

Design Decisions

  • Commit state and the outbox event atomically where the data store supports it.
  • Carry stable event, idempotency and correlation identifiers end to end.
  • Validate AI output before authorization or execution.
  • Bound retries and send exhausted or ambiguous cases to a dead-letter path and review.

Risks & Trade-offs

Outbox relays and consumers can publish or receive duplicates. Schema evolution breaks independent consumers. Model nondeterminism complicates replay, and unbounded retries amplify cost and effects. Human review improves control but adds queueing and operational load.

When to Use / Not Use

Use this pattern for asynchronous enrichment where consumers can tolerate delay and downstream effects support idempotency. Do not use it for a synchronous decision that must complete inside the initiating transaction, or when an irreversible target cannot accept an idempotency key or support reconciliation.

Sources