01
Broker Selection
RabbitMQ, Kafka, Redis Streams, IBM MQ or ActiveMQ, decided per workload from routing needs, replay, ordering, throughput and the team that will operate it. Mixed estates are normal, and we design for them.
Event-Driven Architecture Consulting
Event-Driven Architecture Consulting: Design the Event Streaming Platform, Pick the Broker, Run It After Go-Live
Event-driven architecture consulting from AceMQ covers the decisions that decide whether an event-driven system holds up in production: which broker for which workload, how services publish and consume events, how failures are retried and compensated, and who is on the pager after launch. We advise on the brokers we run for customers: RabbitMQ, Kafka, Redis Streams, and migrations off IBM MQ and ActiveMQ.
- enterprise customers
- 130+
- countries served
- 26+
- stages of operational cover after go-live
- 4
Trusted for Mission-Critical Messaging by Teams in Finance, Healthcare, Defense, Telecom, and More
Customers
Partners
Is This You?
You probably need this if…
- 01
Services call each other synchronously and one slow dependency stalls the whole chain
- 02
The team is debating RabbitMQ against Kafka against a cloud queue and nobody neutral is in the room
- 03
A service commits to its database and then publishes an event, and sometimes the event never goes out
- 04
An IBM MQ or ActiveMQ estate has a renewal or support decision coming and no target architecture
- 05
Microservices multiply, but nobody owns event contracts, naming or versioning
- 06
A broker is in place and was designed at go-live. Dead-letter queues fill, consumers lag and retries pile up
- 07
You want the people who design the system to still be there when it pages someone
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your Messaging estate when the engagement closes.
Before
Broker choice is a preference, argued from blog posts and vendor material.
After
A written decision per workload class, with the reasons, the trade-offs and the conditions that would change the answer.
Before
Events are published when the code remembers to, and consistency between the database and the broker depends on luck.
After
A consistency pattern per service: transactional outbox, change data capture with Debezium, or idempotent consumers, chosen for the service and its database.
Before
Failure handling is whatever each team wrote last: immediate retries, silent drops, queues nobody drains.
After
One retry, dead-letter and compensation standard, with ownership for every dead-letter queue.
Before
The design ends at the architecture diagram, and operations is somebody else's problem.
After
A reference architecture with monitoring, capacity and failover decisions in it, and an agreed operating model on the support ladder.
Scope
What's covered
- 02
Messaging Patterns
Publish and subscribe, work queues with competing consumers, request and reply, and event streams, mapped to the broker features that implement them.
- 03
Consistency Patterns
Transactional outbox, change data capture with Debezium, idempotent consumers and sagas, so the database and the event stream agree after a crash.
- 04
Event Sourcing and CQRS
Where they pay for their complexity and, more often, where they do not. We say which when we see your domain.
- 05
Reliability Design
Publisher confirms and consumer acknowledgements, retry and dead-letter flows, ordering assumptions, backpressure and the failure of a single consumer or node.
- 06
Event Contracts and Schemas
Naming, versioning, compatibility rules and ownership, so one team's change does not break another's consumer.
- 07
Security and Operability
TLS, authentication and authorization per service, monitoring and alerting design, capacity and disaster recovery decisions made at design time.
- 08
Migration Paths
Phased moves off IBM MQ or ActiveMQ, with parallel running and a rehearsed rollback, routed workload by workload.
The Engagement
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
- Phase 1Days, by number of systems
Landscape and Requirements
We map the services, the data they exchange, the brokers already in place and the constraints that matter: ordering, loss tolerance, latency, volume, regulatory needs and the skills of the team that will run it.
You receive
- Workload inventory by messaging pattern
- Constraint register
- Questions that need an owner before design
- Phase 2Days, by number of workload classes
Broker and Pattern Decisions
Each workload class gets a broker, a pattern and a consistency approach, written as decision records with the alternatives considered and what would change the answer.
You receive
- Decision records per workload class
- Broker comparison against your constraints
- Phase 3Scoped per engagement
Reference Architecture
The blueprint: topology, queue and topic design, event contracts, retry and dead-letter standards, security, monitoring and failover, written for your engineers to build from.
You receive
- Reference architecture document
- Retry, dead-letter and idempotency standard
- Monitoring and alerting design
- Phase 4Scoped per engagement
Prove It
A proof of concept or load test against the riskiest assumption, built with your engineers, so the design is tested before it is rolled out.
You receive
- Test plan and results
- Adjusted design where the test disagreed
- Phase 5Optional, on a cadence you choose
Go-Live and Operating Model
Review of the rollout and an agreed operating model on the support ladder, from reactive support to managed operation, so the design has an owner on the day it goes live.
You receive
- Go-live review
- Operating model and support stage recommendation
What event-driven architecture consulting covers
Event-driven architecture consulting is architecture work on how services communicate through events or messages: the broker, the patterns and the failure handling. When the same events feed analytics, the design also covers the data streaming platform behind them. The work product is a set of decisions your engineers can build from, plus an operating model for after go-live. Most of the cost of a poor design shows up later as lost messages, stuck queues, duplicate processing and incidents nobody can explain.
AceMQ approaches this from the operations side. We run RabbitMQ, Kafka and Redis for customers and support IBM MQ and ActiveMQ estates, so the advice comes from what fails in production. Because our message broker consulting spans all of these brokers, a recommendation can be RabbitMQ for one workload and Kafka for the next.
If you already run a broker and want it checked first, see the RabbitMQ health check
For the Kafka equivalent, see the Kafka health check
Choosing the broker: RabbitMQ, Kafka, Redis Streams, IBM MQ and ActiveMQ
The broker decision follows the workload, not the other way round. The table summarizes how we think about the brokers we support, using each project's own documentation for the facts.
| Broker | Model | Strongest fit | Watch for |
|---|---|---|---|
| RabbitMQ | Exchanges route messages to queues. Quorum queues are replicated and documented as the default choice for a replicated, highly available queue. Streams add an append-only log with non-destructive reads and replay. | Routing, work distribution, request and reply, per-message acknowledgement, and mixed workloads that also need a replayable stream. | Streams complement queues. Per the RabbitMQ documentation they lack priorities, dead-letter exchanges and TTL, so queue-shaped work still belongs on queues. |
| Apache Kafka | A partitioned, replicated log. Consumers in groups track offsets and can replay within the retention period. | Many independent consumers of the same events, replay, ordering per key, high throughput and stream processing. | At-least-once is the default. Exactly-once covers reading and writing Kafka topics. Writes to outside systems need the other system's cooperation. |
| Redis Streams | An append-only log inside Redis, with consumer groups, acknowledgement and tools to claim entries a failed consumer left pending. | Light event flows where Redis is already in the stack and the data set fits the memory and persistence you run. | Redis documents that messages may be processed more than once or not at all, depending on consumer failures and the limits of Redis persistence and replication. |
| IBM MQ | Queue-based enterprise messaging with a long history in transactional systems. | Existing estates where it runs correctly and the decision is whether to keep, bridge or move. | Licensing and support terms, and legacy code tied to its API. Moves are phased and workload by workload. |
| ActiveMQ | Open-source JMS broker, as Classic or Artemis. | Existing JMS estates and Java applications that depend on JMS semantics. | Which line you run, and its support position. |
Mixed estates are common and often correct. A pattern we see repeatedly in event-driven systems is RabbitMQ carrying commands, routing and request and reply, with Kafka carrying the event history that many consumers read. The design question is where each fact is stored and which system is the source of truth.
The long version of the Kafka decision is in our RabbitMQ versus Kafka comparison
For routing and protocol differences, read RabbitMQ versus Kafka routing and protocols
Weighing Redis against Kafka? See Redis versus Kafka
Weighing RabbitMQ against Redis? See RabbitMQ versus Redis
Coming from IBM MQ? Read IBM MQ versus RabbitMQ
Coming from ActiveMQ? Read ActiveMQ versus RabbitMQ
Event-driven patterns we design, and where each one breaks
Each pattern solves one problem and creates another. The review names both, so the team chooses with the cost in view.
| Pattern | What it solves | Where it breaks | What we design |
|---|---|---|---|
| Publish and subscribe | Many consumers react to the same event without the publisher knowing them. | Consumers that need different delivery guarantees, and fan-out nobody can trace. | Exchange or topic layout, consumer ownership, and a record of who consumes what. |
| Work queue | Competing consumers share a stream of tasks. | Poison messages, retry storms and unbounded backlogs. | Prefetch, acknowledgement mode, dead-letter and retry flow, queue length limits. |
| Transactional outbox | Updating a database and sending a message atomically without two-phase commit: the message is written in the same local transaction, and a relay publishes it. | The relay can publish a message twice if it crashes after publishing, so consumers must be idempotent. | Outbox table design, relay choice (log tailing or polling) and consumer idempotency. |
| Change data capture with Debezium | Streams committed database changes as events without changing application code. | Source database retention and log settings, and replayed events after a restart. | Connector design, topic and key choice, and consumer deduplication. |
| Saga | A business transaction that spans services, as a sequence of local transactions with compensating steps if one fails. | Compensations are not automatic. They must be designed for every step, and choreographed flows need a trace of who reacts to what. | Choreography or orchestration per flow, and the compensation for each step. |
| Event sourcing | Stores every change as an event, so state can be rebuilt by replaying them. | Replay time, event schema evolution and the operational cost of the event store. | Whether the domain needs it, and what to store. |
| CQRS | Separate models for updates and for reads. | Martin Fowler cautions that for most systems it adds risky complexity, and advises limiting it to specific bounded contexts. | Where a separate read model earns its cost, if anywhere. |
The outbox pattern and change data capture are the two most common answers to the dual-write problem. With Debezium, the Outbox Event Router transformation reads an outbox table, routes each row by its aggregate type to a topic, uses the aggregate ID as the Kafka message key so ordering holds per key, and exposes an event ID that consumers can use to remove duplicates.
Change data capture in production, including Debezium incident patterns, is covered by Debezium CDC support
For the Kafka-specific version of these patterns, read Kafka event-driven architecture: patterns and pitfalls
A named example of choosing the lighter option: American National replaced a Kafka-based change capture pipeline with Debezium and RabbitMQ, described in the American National use case
Failure modes we design out before go-live
Event-driven systems fail in a small number of repeating ways. Each of these is cheaper to remove in a design review than in an incident.
- Lost publishes — A publisher that does not use confirms cannot tell whether the broker accepted a message. In RabbitMQ, a confirm for a persistent message on a durable queue arrives after it is written to disk, and a replicated quorum queue confirms only after replication to a quorum.
- Duplicate processing — Retries and redelivery are normal. RabbitMQ documents that consumers must be prepared to handle redeliveries and should be built with idempotence in mind, and Kafka's default guarantee is at-least-once. Every consumer gets an idempotency rule.
- Retry storms — A downstream bottleneck floods error queues, and immediate retries make it worse. We design delayed retry, dead-letter handling and an owner who drains each dead-letter queue.
- Ordering assumptions — Ordering holds per partition or per queue, not across a system. Event keys and partition design follow the entities whose order matters.
- Schema drift — A producer changes a field and a consumer breaks. Contracts get an owner, a compatibility rule and a deprecation path.
- Shared clusters — One team's workload sets the failure risk for every team on the cluster. We decide where isolation is worth its cost.
A retry and dead-letter case from a payment environment is in the retry automation use case
After go-live: the four-stage support ladder
A design is only as good as the team that runs it. For RabbitMQ, Kafka and Redis or Valkey we offer four stages of operational cover, and we recommend one as part of the engagement so the architecture has an owner from day one.
| Stage | What it is | Fits when |
|---|---|---|
| Stage 1: Reactive support | Senior engineers on call for incidents, with an emergency response SLA. | Your team runs the platform and wants a safety net. |
| Stage 2: Proactive support | Reactive support plus monitoring through AceMQ's observability setup, so problems are caught before users report them. | You want early warning and regular reviews without handing over operations. |
| Stage 3: Managed on your infrastructure | AceMQ operates the platform inside your cloud account or data center. | Data must stay in your environment and you do not want to staff the platform. |
| Stage 4: Managed on AceMQ's infrastructure | AceMQ operates the platform on its own infrastructure, hosted for you. | You want the platform run for you without owning the infrastructure. |
IBM MQ and ActiveMQ estates are covered by support rather than by the managed stages.
RabbitMQ support is described on RabbitMQ support
Managed operation is described on managed RabbitMQ services
and, for the other brokers, on managed Kafka services
Support and managed cover after the design
A design engagement ends with a recommended stage, so an event streaming platform built on Kafka or RabbitMQ has 24x7 cover from day one. Start with Stage 1 or 2 escalation cover, or hand day-to-day operation to AceMQ.
Kafka escalation cover and the 15-minute P1 SLA are on Kafka support
AceMQ running the platform for you is described on managed open source
The wider set of AceMQ solutions is on the Solutions hub
Moving off IBM MQ or ActiveMQ without breaking the event flow
Legacy MQ estates are rarely one workload. They mix event streaming, transactional messaging and batch integration, and a blanket move to any single replacement tends to fail. Our approach classifies each workload by messaging pattern, ordering and latency needs, then routes it: Kafka for event streaming and high-throughput append workloads, RabbitMQ for transactional, routing-heavy and request and reply workloads.
Moves run in phases, with parallel operation and behavior validation before each cutover. American National Insurance, for example, moved Windows-based IBM MQ queues to RabbitMQ first and built a roadmap for its mainframe queues as a later phase.
The migration service, with IBM's lifecycle dates by version, is IBM MQ migration and alternatives
For the modernization approach, read the IBM MQ modernization guide
and for JMS estates, the ActiveMQ modernization guide
Where architecture consulting stops
- Design and review, not build — We write the reference architecture, review designs and test assumptions with your engineers. Your developers write the application code.
- No outcomes promised in advance — We do not quote throughput, cost or availability figures before we have seen your workload.
- Cloud-native queues — We advise on how they sit beside the brokers we run. We do not operate Amazon SQS, Azure Service Bus or Google Pub/Sub for you.
- Scope is quoted per engagement — A review of one system and a design for a platform are different pieces of work.
For multi-broker support under one contract, see enterprise MQ support
FAQ
Questions about Messaging architecture consulting
What is event-driven architecture consulting?
It is architecture work on how services communicate through events or messages. It covers broker choice, messaging and consistency patterns, failure handling and the operating model, and ends in decision records and a reference architecture your engineers can build from.
What is the difference between microservices and event-driven architecture?
They answer different questions. Microservices describe how a system is split into small, independently deployable services. Event-driven architecture describes how components communicate: by publishing events or messages that other components react to, instead of calling each other directly. The two are not alternatives. Microservices can talk over synchronous calls such as REST or gRPC, or through events, and most large estates mix both. Events decouple services in time and failure, at the cost of eventual consistency, so the design work is deciding which interactions should be events, which should stay synchronous, and how to keep data consistent between them with patterns such as the transactional outbox and sagas.
Do we need Kafka for an event-driven architecture?
Not necessarily. Kafka is a strong fit where many consumers read the same events, replay matters and ordering per key is enough. RabbitMQ is a better fit for routing, work distribution and request and reply, and can also hold a replayable stream. Many estates use both. We decide per workload.
Is Kafka an event-driven architecture?
No. Kafka is an event streaming platform: a distributed, replicated log that services publish events to and read them from. Event-driven architecture is a design style in which components react to events instead of calling each other directly. Kafka is one of the most common foundations for it, alongside RabbitMQ and other brokers, but running Kafka does not make a system event-driven, and an event-driven system does not need Kafka.
What is the transactional outbox pattern, and do we need Debezium for it?
The outbox pattern writes the outgoing message to a table in the same database transaction as the business change, and a separate relay publishes it. The message is sent if and only if the transaction commits. Debezium is one way to relay it, by reading the database log. A polling publisher is the other. Either way, consumers must be idempotent, because the relay can publish twice.
Can you run an architecture review of an event-driven design we already built?
Yes. An architecture review reads the design against your real traffic, failure history and constraints, covering the message queue architecture as well as the event streams, and returns a ranked list of changes. If a broker is already running, a health check of that broker is a sensible companion.
Do you also run the brokers after go-live?
Yes, if you want it. For RabbitMQ, Kafka and Redis or Valkey there are four stages: reactive support, proactive support with monitoring, managed operation on your infrastructure, and managed operation on AceMQ's infrastructure. IBM MQ and ActiveMQ are covered by support.
Do you consult on IBM MQ and ActiveMQ migrations?
Yes. We classify each workload by pattern and route it to RabbitMQ or Kafka, then run the move in phases with parallel operation and a rollback plan.
How much does event-driven architecture consulting cost?
It is scoped on the number of systems, workload classes and the depth of design, not on seats. We do not publish a price list. Tell us what you run and what you are deciding and we will come back with a written quote within 24 hours.
Let's talk
Talk Through Your Event-Driven Architecture
Tell us which brokers you run, what you are deciding and when. We will scope the work and come back with a written quote within 24 hours.
Get in Touch
Talk to an AceMQ Expert
Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.