Proven with Industry Leaders
Event-driven integration across queues, streams, and APIs
No single platform does every integration job well. Message queues, event streams, APIs, and integration engines each solve a different problem, and the design work is deciding which flow belongs where. We work across all four, so the choice follows the workload rather than the product we happen to sell. Our Insights on Private AI & Data Architecture cover what the data layer has to deliver before an AI agent can act on it.
Message queues
A message queue hands each message to one consumer and confirms it was processed. It suits work that must happen once: a payment instruction, a policy update, a job for a worker. RabbitMQ, Amazon MQ, IBM MQ, and ActiveMQ all do this well.
Kafka event streaming
Kafka keeps events in an ordered log that many consumers can read at their own pace and replay later. It suits facts other systems need to know about: a claim was filed, an address changed, a payment cleared.
APIs and gateways
Some interactions need an answer now: a quote, a balance, an eligibility check. API gateways handle those requests and apply security and rate limits, while events and queues carry the work that can happen behind them.
The integration layer
An integration engine such as WSO2 Micro Integrator connects systems, transforms messages between formats, and enforces policy across APIs, queues, and streams. It is a different job from moving messages, and it needs its own tool.
For a property and casualty insurer, a core team of two manages and develops a platform built on WSO2 API Manager, RabbitMQ, and Kafka together, and has ramped to ten engineers to deliver multiple initiatives. The team model is set out under managed integration services.
Message queue support: RabbitMQ, Amazon MQ, IBM MQ, and more
Message queues are not legacy. Banks and insurers run payments, policy changes, and back-office work on them because they deliver each message to one consumer, confirm it was handled, and support transactions and request-reply patterns. Those are jobs a streaming platform does not replace.
We support RabbitMQ, Amazon MQ, IBM MQ (formerly MQSeries and WebSphere MQ), ActiveMQ, and other message queue products. The core concepts of queues, acknowledgements, routing, and durability carry across brokers, and we work within the differences each one has.
Support and managed services
Incident response, root-cause analysis, patching, and day-to-day operation of your brokers under an operating agreement, with monitoring from our network operations center.
Clustering and performance
Cluster design, queue and exchange layout, high availability, and tuning for the throughput and latency your workloads need, including queues that back up under load.
Upgrades and broker migrations
Version upgrades with a tested rollback, and moves between brokers or from self-managed brokers to Amazon MQ, planned so producers and consumers keep working through the change.
Integration with the rest of the estate
Connecting queues to APIs, integration flows, and Kafka, so messages move between systems with the security, routing, and audit trail each flow needs.
RabbitMQ consulting and managed services for a well-known P&C insurer
We ran a RabbitMQ managed services and support contract for a well-known property and casualty insurer for the full length of the relationship, operating and supporting its RabbitMQ brokers in production.
Event-driven architecture, answered plainly.
Event-driven architecture
What is event-driven architecture?
Event-driven architecture is a way of connecting systems in which they react to events, such as a claim being filed or a payment clearing, instead of calling each other directly and waiting for an answer. It uses message queues, event streaming platforms such as Kafka, and APIs together, each for the work it suits.
What does event-driven architecture consulting cover?
It covers deciding which flows should use a message queue, which should use event streaming, and which should stay as API calls; designing the topics, queues, and schemas; and planning how the new design runs alongside what you have today. Duczer East then builds, supports, and runs the result.
Message queues and Kafka
RabbitMQ vs Kafka: what is the difference?
RabbitMQ is a message broker: it routes each message to a consumer, confirms it was handled, and then removes it. Kafka is an event streaming platform: it keeps events in a log that many consumers can read independently and replay later. RabbitMQ suits commands and tasks that must be processed once. Kafka suits events that many systems need to know about, and workloads where replay and history matter, such as audit.
Do we need to replace our message queue to adopt Kafka?
No. Most organizations run both. Message queues remain the right tool for transactional, point-to-point delivery. Kafka is added alongside them for workloads that need replay or many consumers, and connectors can copy messages from the queue into Kafka without changing the existing flow.
Can you migrate workloads from RabbitMQ or another message queue to Kafka?
Yes, when the workload needs what Kafka provides. We assess each flow first, because many belong on a queue. For the ones that should move, we run the old and new paths side by side and cut over only once the new path is proven.
Message queue support
Which message queue products do you support?
RabbitMQ, Amazon MQ, IBM MQ, ActiveMQ, and other message queue products, alongside Kafka for event streaming. The core concepts of queues, acknowledgements, routing, and durability carry across brokers, and we work within the differences each product has.
Do you provide RabbitMQ managed services?
Yes. We provided RabbitMQ managed services and support to a well-known property and casualty insurer for the full length of the relationship, and we provide RabbitMQ support, upgrades, and managed services under a defined operating agreement.
Do you offer RabbitMQ consulting?
Yes. Our RabbitMQ consulting covers cluster design, queue and exchange layout, high availability, performance tuning, upgrades, and the choice between RabbitMQ, another broker, and Kafka for each workload. The same team supports what it designs.
Do you support Amazon MQ?
Yes. Amazon MQ is AWS’s managed broker service for ActiveMQ and RabbitMQ. AWS operates the brokers; we support the configuration, queues, clients, and applications that remain yours, and we plan migrations from self-managed brokers to Amazon MQ.
Do you work with IBM MQ, formerly MQSeries?
Yes. IBM MQ, known earlier as MQSeries and WebSphere MQ, is built for transactional, once-only delivery and is common in banking and insurance. We support it alongside other brokers, and we connect it to Kafka where new consumers need its messages.
Engagement and cost
How do you monitor message queues and event streams?
From our network operations center, with coverage up to 24x7 as agreed in each contract. We watch queue depth, consumer health, message rates, and broker resources, and route problems to the engineers who know your estate.
What does message queue or event-driven architecture support cost?
It is quoted per deployment, based on the brokers and clusters you run, the coverage you need, and whether you want support only, managed services, or an outsourced team. We scope it after a short review of your estate.