What does AceMQ Apache Pulsar support include?

Our Pulsar support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, broker and BookKeeper tuning, metadata store health advisory, quarterly capacity reviews, and Kafka migration or multi-layer onboarding support. Every ticket is handled by a named senior engineer — there is no tier-1 triage layer and no per-incident charge.

Do you support the BookKeeper storage layer, or just the broker?

Both, and this distinction matters. Pulsar's storage is a separate BookKeeper layer of bookies, and a large share of production incidents originate there — disk IO contention, journal/ledger volume misconfiguration, ensemble placement — not in the broker itself. We diagnose across both layers as standard practice.

Can you fix producers getting throttled unexpectedly?

Yes. This is almost always a backlog quota policy issue — either the quota threshold is set lower than actual traffic requires, or the topic's backlog quota retention policy (producer_exception, producer_request_hold, or consumer_backlog_eviction) doesn't match what the team actually intended. We identify the mismatch and correct the policy.

How fast do you respond to a Pulsar production outage?

P1 emergencies — a broker instability cascade, a bookie under critical IO pressure, or a metadata store quorum issue — get a 15-minute first response with a senior engineer joining a live bridge. P2 critical issues are 1 hour, P3 high-priority 4 hours, and P4 standard questions next business day. These are contractual, not best-effort targets.

We're migrating from Kafka to Pulsar. Can you help?

Yes. We plan and execute Kafka-to-Pulsar migrations, including onboarding your operations team to the broker/bookie architectural split, which is the most common source of confusion for teams new to Pulsar. We also assess honestly whether Pulsar's multi-layer model fits your actual use case before recommending it.

Do you support geo-replication and tiered storage offload?

Yes. We design and troubleshoot multi-region geo-replication, including replication lag diagnosis, and we fix tiered storage offload misconfigurations that leave cold data present in object storage but inaccessible to consumers.

How is AceMQ Pulsar support priced?

Support is priced as an annual contract based on your environment size, required SLA tier, and coverage hours — not per incident or per ticket. That means calling us during an outage never carries a cost decision. Contact us for a quote; we turn them around within 24 hours.

Apache Pulsar Support

24/7 Apache Pulsar Support with a 15-Minute Emergency SLA

AceMQ supports Apache Pulsar's multi-layer architecture in production — BookKeeper bookies under disk and IO pressure causing cluster-wide write latency spikes, backlog quotas triggering unexpected producer throttling, and ZooKeeper metadata store issues cascading into broker instability. Every ticket reaches a named senior engineer who understands both the broker and bookie layers.

Senior Apache Pulsar engineers on call right now — 24/7/365

15 min emergency SLA24 /7 global coverage130 + enterprise customers26 + countries served

Available Now

Book a free Consultation.

Prefer to chat first?

Prefer to E-mail?

info@acemq.com

Trusted for mission-critical Apache Pulsar by teams in finance, healthcare, defense, and telecom

Escalation Path

Your first hour of a Apache Pulsar outage

Most vendors publish an SLA number. This is what actually happens, minute by minute, when you page a senior AceMQ engineer.

T+0

You page us

Phone, email, or Slack — any channel reaches the on-call senior engineer directly. No web form, no tier-1 queue.

T+15

Named engineer live

A senior engineer who already knows your environment joins a live bridge. Zero cold-start, no re-explaining your topology.

T+30

Root cause isolated

Direct broker access, log and metric review, and a working hypothesis with a rollback plan before we touch anything.

Post

Written RCA

Documented root cause, the fix applied, and the prevention steps — delivered after every P1, not just when asked.

Response Times

SLA tiers, contractually guaranteed

Every tier reaches a senior Apache Pulsar engineer. There is no tier-1 triage layer to get through.

P1 — Emergency

15 min

Production down, messages not flowing, cluster or broker failure

P2 — Critical

1 hour

Severe degradation, rising error rates, approaching capacity limits

P3 — High

4 hours

Performance issues, configuration problems, non-critical failures

P4 — Standard

Next day

Questions, guidance, best practices, non-urgent improvements

Incident Triage

Apache Pulsar problems we fix every week

These are real symptoms from real Apache Pulsar production environments — and the first thing our engineers check when one comes in.

Symptom you're seeingWhat we check firstTypical resolution

Write latency spikes cluster-wide with no obvious broker cause

What we check firstBookKeeper bookie disk IO and journal/ledger volume separation. Pulsar's storage layer is a common blind spot for teams used to Kafka's single-layer model — a single overloaded bookie degrades writes for every topic with an ensemble that includes it, not just its own partitions.

Typical resolution1–3 hours

Producers suddenly get throttled or messages start getting rejected

What we check firstBacklog quota configuration and current backlog size against the configured retention policy. Whether the topic is set to producer_exception, producer_request_hold, or consumer_backlog_eviction determines whether this is throttling or actual message loss — and that policy choice is easy to get wrong.

Typical resolutionUnder 2 hours

Retention behaves unexpectedly — messages disappear early or never expire

What we check firstNamespace-level and topic-level policy precedence. Pulsar's policy hierarchy (namespace default vs. explicit topic override) is a frequent source of retention and deduplication behaving differently than the admin expected.

Typical resolution1–2 hours

Brief unavailability or latency blips during normal operation

What we check firstBundle unload and split events in broker logs. Pulsar rebalances topic ownership across brokers by splitting and unloading bundles automatically, and this is often mistaken for an incident when it's actually expected load-balancing behavior — though we verify it isn't masking a real imbalance.

Typical resolutionUnder 1 hour

Geo-replicated clusters drift out of sync

What we check firstReplication backlog and network latency between clusters, plus whether a replicator connection dropped and didn't recover cleanly. Geo-replication lag compounds quietly until a failover reveals how far behind the remote cluster actually is.

Typical resolution2–4 hours

Broker instability that seems to start with metadata operations

What we check firstZooKeeper (or configured metadata store) session timeouts and quorum health. Because brokers, bookies, and topic ownership all depend on the metadata store, a struggling ZooKeeper quorum cascades into broker-level symptoms that look unrelated at first glance.

Typical resolution2–4 hours

Old data offloaded to S3 can't be read back

What we check firstTiered storage offload configuration and the offload driver's credentials/permissions against the target bucket. A misconfigured offload threshold or a permissions change on the bucket leaves cold data present but inaccessible, which surfaces only when a consumer actually seeks into it.

Typical resolution2–4 hours

Resolution times reflect typical Apache Pulsar engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.

Not on the list? Tell us what's breaking

Support In Practice

Apache Pulsar problems we've already solved

Representative engagements showing how these incidents get diagnosed and closed under an AceMQ support contract.

All use cases

Remediation

Apache Pulsar BookKeeper IO Remediation

Global Payments Processor

Resolving cluster-wide write latency caused by bookie journal and ledger device contention, and restoring write quorum headroom.

Apache PulsarApache BookKeeperKubernetes

Read case study

Support

Apache Pulsar Backlog Quota and Producer Throttling Support

Public Sector Agency

Diagnosing producers blocked by backlog quota enforcement when a slow or abandoned subscription prevents the backlog from clearing.

Apache PulsarApache BookKeeperKubernetes

Read case study

Assessment

Apache Pulsar Cluster Sizing and Architecture Assessment

Telecommunications Operator

Sizing brokers, bookies, and metadata for a Pulsar deployment against real throughput, retention, and durability requirements.

Apache PulsarApache BookKeeperZooKeeper

Read case study

What's Included

Everything in your Apache Pulsar support contract

No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.

Emergency Incident Response

A bookie under IO pressure, a broker instability cascade, or a metadata store quorum issue. A senior engineer joins a live bridge within 15 minutes with access across the broker and bookie layers — not a ticket acknowledgement.

Root Cause Analysis

Every P1 closes with a written RCA: what failed, why, the fix applied, and the specific config or infrastructure change that prevents recurrence.

Broker & BookKeeper Tuning

Journal/ledger disk separation, backlog quota and retention policy design, and bundle assignment tuning against your actual topic count and throughput profile.

Metadata Store Health Advisory

Proactive monitoring of ZooKeeper (or your configured metadata store) quorum health, since a single degraded metadata node can cascade into cluster-wide broker instability.

Capacity & Storage Reviews

Quarterly reviews of bookie disk headroom, backlog growth trends, and tiered storage offload behavior so you size ahead of demand rather than reacting to a throttled producer.

Kafka Migration & Multi-Layer Onboarding

Migration planning from Kafka, including mapping the broker/bookie architectural split for ops teams new to it, plus geo-replication design for multi-region deployments.

Anywhere You Run It

We support Apache Pulsar wherever it's deployed

Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.

StreamNative CloudSelf-managed Pulsar clustersAWS (EC2, EKS)Google Cloud (GKE)Microsoft Azure (AKS)Kubernetes & OpenShiftBare metal & on-premiseTiered storage to S3/GCSGeo-replicated multi-regionAir-gapped / no outbound access

Why AceMQ

What you get that you don't get elsewhere

Named Engineers, Zero Cold Start

The same senior engineers stay on your account. They know your bundle layout, your bookie ensemble configuration, and your replication topology — so a P1 starts with diagnosis, not twenty minutes of explaining your environment.

No Tier-1 Triage Layer

You reach a senior Pulsar engineer directly by phone, email, or Slack. No help desk collecting information to pass along, no escalation approval process standing between you and someone who can fix it.

We Know the Storage Layer, Not Just the Broker

Pulsar's split broker/bookie architecture is exactly where teams coming from Kafka get surprised. We treat BookKeeper as a first-class diagnostic target, not an afterthought behind the broker logs.

Genuine Follow-the-Sun Coverage

Engineers across 26+ countries and every time zone. Your 3am latency spike is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to wake up.

Proactive, Not Just Reactive

Quarterly health checks on bookie disk and metadata store quorum health, plus shared intelligence across our support base. When a version-specific bug surfaces on one customer's cluster, every affected customer hears about it before it reaches their production.

Honest About the Operational Complexity

Pulsar's multi-layer architecture buys real flexibility but real operational surface. We tell customers plainly when that trade-off fits their use case and when a simpler system would serve them better.

FAQ

Apache Pulsar support questions

Your Pulsar Cluster's Storage Layer Shouldn't Be a Blind Spot

Whether you need emergency response tonight or a support contract that treats BookKeeper as seriously as the broker, AceMQ staffs every engagement with a named senior Pulsar engineer. Support quotes returned within 24 hours.

Get in Touch

Talk to a Support Expert

Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.

305-204-2607

info@acemq.com

66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.