Event-Driven Integration Patterns for Legacy Middleware Modernisation

How to migrate from monolithic middleware (BizTalk, MuleSoft, TIBCO) to event-driven architectures using modern open-source tooling.

Covers the strangler fig migration pattern, Symfony Messenger transport design, Redis Streams vs Kafka selection criteria, dead-letter queue architecture, schema registry governance, and observability for event pipelines. Includes migration playbooks for BizTalk, MuleSoft, and TIBCO environments.

EDITION · Q1 2025 · 42 PAGES

INTEGRATION

Event-Driven Integration Patterns

CELESDEV Solutions · celesdev.com

Executive Summary

From synchronous coupling to event-driven resilience

Legacy middleware platforms create synchronous coupling that propagates failures across systems. Event-driven architectures decouple producers from consumers, absorb load spikes gracefully, and enable independent deployability. The migration path is well-understood but requires careful sequencing.

This document consolidates patterns from five middleware modernisation engagements, covering SAP, Oracle EBS, and custom legacy system integrations.

1

Strangler fig is the only safe migration pattern

Running new and legacy systems in parallel with traffic routing allows incremental migration without big-bang cutover risk. Every flow can be rolled back in seconds.

2

Choose transport by throughput, not trend

Redis Streams handles <100k events/hour with lower operational overhead than Kafka. Use Kafka when you need Kafka-scale throughput or need its log retention guarantees.

3

Dead-letter queues are non-negotiable

Silent message loss is worse than visible failure. Three-tier retry + DLQ with alerting and replay capability is the minimum viable reliability pattern.

4

Schema registry prevents silent breaking changes

Producer-consumer contracts validated against a registry at deployment time catch incompatibilities before they cause production incidents.

Reference Architecture

Migration Stack

Event-Driven Integration Reference Stack

Routing Layer · Feature Flags · Strangler Fig

Event Producers · SAP CDC / Webhooks / Batch

Message Transport · Redis Streams / Kafka

Schema Registry · Confluent / AWS Glue

DLQ + Retry · Monitoring · Replay API

Author: CELESDEV Solutions — Integration & Data Practice.

Applicable contexts: BizTalk Server migration, MuleSoft replacement, SAP integration modernisation, legacy ESB decommissioning.

Full document includes Symfony Messenger transport configuration examples, Redis Streams consumer group patterns, and a migration readiness assessment checklist.

CELESDEV Solutions | celesdev.com | business@celesdev.com

2 of 3 - Executive Summary

Event-Driven Integration Patterns

CELESDEV Solutions | celesdev.com

Pattern Catalog

Core event-driven patterns explained

TRANSACTIONAL OUTBOX

Write events to an outbox table in the same database transaction as the business operation. A CDC or polling relay publishes them to the message bus. Eliminates dual-write and ensures at-least-once delivery.

SAGA (CHOREOGRAPHY)

Each service listens for events and publishes its own events to drive the next step. No central coordinator. Scales well; compensating transactions handle failures. Requires careful event schema design.

CQRS

Separate read and write models. Commands mutate state; queries read from a denormalised projection. Events propagate mutations to read-side projections asynchronously. Useful when read and write loads differ significantly.

EVENT SOURCING

Store state as an append-only log of events rather than mutable rows. Current state is derived by replaying the event log. Provides full audit trail and temporal queries. Adds operational complexity; use selectively.

Migration Phase Guide

Middleware to events migration plan

PHASE	ACTIVITIES	EXIT CRITERIA
Assess	Map all integration flows, classify by criticality and coupling	Integration inventory complete, risk scored
Route	Deploy feature-flag routing layer in front of legacy middleware	100% of traffic routable; rollback in <30s
Migrate	Rebuild flows on new transport; validate with shadow traffic	New flow handles 100% load, parity confirmed
Retire	Cut traffic to new path, decommission legacy flow after 30 days	Legacy instance stopped, licences reclaimed

DLQ standard: Every consumer must implement three-tier retry (immediate, delayed, final) with a dead-letter queue, alerting on DLQ depth, and a replay API. Silent message loss is never acceptable in production event pipelines.

CELESDEV Solutions | celesdev.com | business@celesdev.com

3 of 3 - Technical Reference