Outbox
The application writes the event to its own database in the same transaction as the change, then a relay publishes it. No lost or phantom events.
Event-driven architecture
Event-driven architecture for systems that cannot stop.
Events let old systems and new ones exchange change without tight coupling. We introduce them one flow at a time, on brokers AceMQ supports.
The short answer
Event-driven architecture lets systems publish facts, such as an order placed, to a broker, and other systems react to them. For legacy estates it reduces point-to-point coupling and gives new services a way to listen without changing the old ones. Ace8 introduces events one flow at a time on RabbitMQ or Kafka, delivered with AceMQ.
Why
Why use events in a legacy estate?
This is how a monolith is usually split safely. See monolith to microservices.
- Decoupling: a producer does not need to know who consumes its messages.
- Gradual migration: a new service can subscribe to events from the old system and replace one function at a time.
- Resilience: a slow or failed consumer does not block the producer, because the broker holds the messages.
- Integration: many systems can react to one change without a new connection per pair.
Choosing
RabbitMQ or Kafka: which fits?
Neither is always right. The choice follows the workload, and some estates run both. AceMQ supports RabbitMQ and Kafka, so the advice is not tied to one product.
| Question | RabbitMQ | Kafka |
|---|---|---|
| Model | Broker that routes messages to queues | Distributed log that consumers read at their own pace |
| Good at | Task queues, request routing, per-message delivery and acknowledgement | High-volume streams, replay, many independent readers |
| Replay of old events | Not its default model | Built in, within retention |
| Operating weight | Lighter to run for most enterprise workloads | Heavier, with more to size and tune |
| Typical replacement for | IBM MQ and other enterprise brokers | Event streaming and analytics pipelines |
Patterns
Which patterns do we use to bridge old and new?
Change data capture
Read database changes from the log and publish them, so legacy code does not have to change. Debezium is a common tool for this.
Strangler routing
Send a slice of traffic or events to the new service while the old one handles the rest.
Idempotent consumers
Consumers tolerate duplicate delivery, which brokers can produce under failure.
Delivered work
What has been delivered?
For American National, an insurer, the AceMQ engineering team migrated IBM MQ to RabbitMQ in phases while refactoring the legacy code around the old broker. In the same work, change data capture that had used Kafka was replaced by Debezium with RabbitMQ, which removed a component from the architecture.
That shows two things: a messaging platform can be replaced without a big-bang cutover, and fewer moving parts is sometimes the right design. Scope figures will be published as the customer approves them. See the case study.
Judgment
When are events the wrong answer?
- The caller needs an answer now, such as a balance check. A synchronous call is simpler.
- The system is small and has two integrations. A broker adds operations work with little benefit.
- The team has no way to monitor queues, retries and dead letters. Add that first.
- Strict ordering across many producers is required and nobody has designed for it.
Method
How do we introduce events safely?
This follows the Ace8 method, and the code changes use the AI-assisted process with engineer review.
- 1
Map the flows
Find which systems send what to whom, and what each assumes about delivery and order.
- 2
Pick one flow
Start with a flow that has clear ownership and low business risk.
- 3
Publish alongside
Emit events while the old integration still runs, and compare results.
- 4
Switch consumers
Move consumers over one at a time. Keep the old path until the new one has proven itself.
- 5
Hand over operations
Agree who monitors the broker. AceMQ supports RabbitMQ and Kafka after go-live.
Proof
Delivered by the AceMQ engineering team.
Phased IBM MQ to RabbitMQ migration with legacy code refactoring
Delivered for American National, an insurer. Kafka-based change data capture was replaced by Debezium with RabbitMQ.
American NationalDelivered by the AceMQ engineering team
After go-live
Keep it running after cutover.
A design in which systems publish events, such as an order placed, to a broker and other systems react to them. It reduces direct coupling between applications.
RabbitMQ suits task queues and message routing, and often replaces enterprise brokers such as IBM MQ. Kafka suits high-volume streams and replay. The workload decides, and some estates use both.
Often yes, using change data capture or the outbox pattern so the old code changes little. Some applications still need targeted refactoring.
Yes. The AceMQ engineering team delivered a phased IBM MQ to RabbitMQ migration with legacy code refactoring for American National, an insurer.
AceMQ supports RabbitMQ and Kafka, so the team that built the platform stays accountable for running it.
Know the cost before anything moves.
A fixed-price assessment gives you the inventory, the risk score and a phased plan. Scope and cost are fixed before the migration starts.
Book a Fixed-Price AssessmentGet in touch
Talk to a modernization engineer
Tell us what you run today. An engineer, not a sales script, replies within one business day.