Skip to content
CONNTAL

Technology family

Messaging and streaming engineers

Conntal vets messaging and streaming engineers on RabbitMQ, Apache Kafka and Confluent, IBM MQ, ActiveMQ, Redis, Pulsar, NATS, Solace and the cloud queues. The screens are written and run by AceMQ practitioners who maintain these platforms in production for regulated enterprises. This is our deepest bench.

  • RabbitMQ
  • Apache Kafka
  • IBM MQ
  • ActiveMQ
  • Solace
  • Cloudera CDP
  • Apache Pulsar
  • Apache Spark
  • Apache Flink
  • Elasticsearch
  • MongoDB
  • PostgreSQL
  • Redis
  • Java
  • Apache Tomcat
  • Kong
  • Databricks
  • Snowflake
  • Apache NiFi
  • Kubernetes
  • Terraform
  • ServiceNow ITOM
  • Apache Airflow
  • Greenplum
  • OpenShift
  • Prometheus

Screened by practitioners

Ace8 and AceMQ engineers, not recruiters

130+

AceMQ enterprise clients across 26+ countries

Contract, C2H or direct

onshore, nearshore or offshore

Platform by platform

What senior looks like on each.

Every platform below carries what a senior engineer demonstrates and the specific things our screen tests. Where we have not confirmed a vetting practitioner, the page says so instead of padding the list.

What the screen tests

  • Quorum queue behaviour when a node is lost versus when quorum is lost
  • Tanzu RabbitMQ and the Broadcom licensing transition — what it changes commercially and operationally
  • Publisher confirms and consumer acknowledgements as the answer to 'did we lose messages'
  • Partition handling strategy and why the default is rarely what a bank wants

Apache Kafka and Confluent

Vetted in house

Separates the two Kafka careers: the person who operates clusters and the person who writes stream applications. Most briefs ask for one and describe the other.

Hire asData engineersDevOps engineers

Run in production byAceMQ: Apache Kafka consulting and supportOSSEVA: Apache Kafka support without Confluent

What the screen tests

  • KRaft versus ZooKeeper — what the migration actually costs on a live cluster
  • Tiered storage and when it changes retention economics
  • Consumer lag as a symptom: rebalancing, partition skew, slow consumers
  • Schema governance, and what breaks when it is absent

IBM MQ

Vetted in house

Understands that IBM MQ estates are usually older than the team running them, and that the risk lives in undocumented channel configuration rather than in the product.

Hire asMiddleware and DevOps engineers

Run in production byAceMQ: IBM MQ support and consulting

What the screen tests

  • Queue manager clustering and what a full repository actually does
  • Channel authentication records and the migration from legacy security exits
  • Transactional integrity across MQ and a database, and where XA genuinely earns its cost

Redis

Vetted in house

Treats Redis as a datastore with durability characteristics rather than as a cache that never fails, and can say what happens to your data during a failover.

Hire asDevOps engineers

Run in production byAceMQ: Redis consulting and supportOSSEVA: Valkey vs Redis compared

What the screen tests

  • Persistence trade-offs: RDB, AOF, and what each loses
  • Cluster mode resharding and the client behaviour during a slot migration
  • When Redis is the wrong tool and a queue or a database is the right one

ActiveMQ

Vetted in house

Knows the Classic and Artemis split and does not assume the answer for one applies to the other.

Hire asDevOps engineers

Run in production byAceMQ: ActiveMQ support and consultingOSSEVA: ActiveMQ Classic to Artemis migration

What the screen tests

  • Classic versus Artemis: when migration is worth it
  • Store and forward behaviour under broker failure
  • JMS semantics that surprise teams coming from Kafka

Cloud queues — SQS, Azure Service Bus, Google Pub/Sub

Vetted in house

Reasons about delivery semantics and cost per message together, because on managed queues those are the same conversation.

Hire asCloud and DevOps engineers

Run in production byAceMQ: Amazon SQS support

What the screen tests

  • At-least-once delivery and idempotent consumer design
  • Visibility timeouts, dead-letter policy and poison-message handling
  • When a managed queue removes operational burden and when it just relocates it

Apache Pulsar

Vetted in house

Understands that Pulsar separates serving from storage — stateless brokers over Apache BookKeeper — and can explain what that changes for scaling, recovery and capacity planning compared with Kafka.

Hire asDevOps engineersData engineers

Run in production byAceMQ: Apache Pulsar consulting and supportOSSEVA: Apache Pulsar extended support

What the screen tests

  • Subscription types — exclusive, shared, failover and key_shared — and the ordering each one preserves
  • BookKeeper ensemble, write-quorum and ack-quorum settings, and what they mean for durability
  • Geo-replication between clusters and how it interacts with subscriptions
  • Tiered storage offload and its effect on retention cost

NATS and JetStream

Vetted in house

Separates core NATS, which is fire-and-forget at-most-once delivery, from JetStream, which adds persistence — and knows which one a given workload actually needs.

Hire asDevOps engineersSREs

What the screen tests

  • Core NATS versus JetStream delivery guarantees
  • JetStream streams, consumers and acknowledgement policies
  • Cluster, supercluster and leaf-node topologies, and when each fits
  • Subject design and wildcard subscriptions

Solace PubSub+

Vetted in house

Designs topic hierarchies deliberately, because in Solace the topic structure is the routing logic — and knows the practical difference between direct and guaranteed messaging.

Hire asMiddleware and DevOps engineers

What the screen tests

  • Topic hierarchy design and wildcard subscriptions
  • Direct versus guaranteed messaging, and queues with topic subscriptions
  • High-availability pairs and disaster-recovery replication
  • Event mesh across sites using dynamic message routing

Why this is the deep bench

Because the vetters do this for a living.

AceMQ is a messaging consultancy first. Its engineers run production RabbitMQ and Kafka estates for enterprises across 26+ countries, with a 15-minute response commitment on incidents. That is not a credential Conntal borrowed for marketing — it is the reason the screens on this page can ask what they ask.

It also means we know how few people genuinely have this experience. Messaging roles take longer to fill than the search firms promise, and we would rather tell you that at the brief.

Adjacent

The stack around the broker.

Messaging never arrives alone. These are the technologies that show up in the same briefs and the same screens.

Runtime

KubernetesEKSAKSGKEOpenShiftVMware Tanzu

Integration

WSO2MuleSoftApigeeSpring AMQPMQTT

Data

Cloudera CDPDatabricksSnowflakeFlinkCDC

Operations

PrometheusGrafanaOpenTelemetryNetflix Dispatch

FAQ

Messaging and streaming: what buyers ask

Something not covered here? Send the requirement and a practitioner answers it, not a sales queue.

Who can staff a RabbitMQ engineer?

Conntal, vetted by AceMQ — a consulting practice whose core product is RabbitMQ, including Tanzu RabbitMQ and the Broadcom licensing transition. Candidates are screened by engineers who maintain production RabbitMQ estates for regulated enterprises rather than by keyword match.

What is the difference between a Kafka engineer and a Kafka developer?

A Kafka engineer usually operates the cluster: brokers, KRaft migration, tiered storage, capacity and rebalancing. A Kafka developer writes the stream applications on top: producers, consumers, stream processing and schema. They are different careers and briefs routinely ask for one while describing the other.

Can you find someone who has run Tanzu RabbitMQ in production?

Yes. Tanzu RabbitMQ and the commercial licensing changes that came with the Broadcom acquisition are part of the AceMQ practice, so it is an area where our screen is specific rather than generic.

Do you staff for FIPS-compliant messaging?

Yes. FIPS-compliant messaging is a named AceMQ capability, and where an engagement requires it we screen candidates against those constraints explicitly rather than treating compliance as a resume keyword.

Which messaging platforms is Conntal deepest on?

RabbitMQ, Apache Kafka and Confluent, IBM MQ, ActiveMQ, Redis, Apache Pulsar, NATS and JetStream, Solace PubSub+ and the cloud queues. Every platform on this page is screened in house by a practitioner who runs it.

Is messaging experience relevant to non-messaging roles?

Constantly. Messaging is where distributed-systems understanding becomes visible, so it appears in the screen for DevOps, SRE and data engineering roles even when the job title never mentions a broker.

Need someone who has actually run the broker?

Tell us the platform and the failure mode you are worried about. An AceMQ engineer will tell you what the role really needs before we source.