Apache Pulsar Support
Last reviewed by Scott Sternloff
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.
Support quotes answered within 1 hour, by a senior engineer.
Planning a build, upgrade or migration instead? See AceMQ Apache Pulsar consulting and services.
Customers
Partners
Incident Triage
These are real symptoms from real Apache Pulsar production environments — and the first thing our engineers check when one comes in.
| Symptom you're seeing | What we check first | Typical resolution |
|---|---|---|
| Write latency spikes cluster-wide with no obvious broker cause | BookKeeper 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. | 1–3 hours |
| Producers suddenly get throttled or messages start getting rejected | Backlog 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. | Under 2 hours |
| Retention behaves unexpectedly — messages disappear early or never expire | Namespace-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. | 1–2 hours |
| Brief unavailability or latency blips during normal operation | Bundle 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. | Under 1 hour |
| Geo-replicated clusters drift out of sync | Replication 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. | 2–4 hours |
| Broker instability that seems to start with metadata operations | ZooKeeper (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. | 2–4 hours |
| Old data offloaded to S3 can't be read back | Tiered 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. | 2–4 hours |
Resolution times reflect typical Apache Pulsar engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.
What's Included
No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.
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.
Every P1 closes with a written RCA: what failed, why, the fix applied, and the specific config or infrastructure change that prevents recurrence.
Journal/ledger disk separation, backlog quota and retention policy design, and bundle assignment tuning against your actual topic count and throughput profile.
Proactive monitoring of ZooKeeper (or your configured metadata store) quorum health, since a single degraded metadata node can cascade into cluster-wide broker instability.
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.
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.
Why AceMQ
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.
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.
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.
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.
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.
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.
Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.
Escalation Path
Every tier reaches a senior Apache Pulsar engineer. There is no tier-1 triage layer to get through.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Pricing
AceMQ Apache Pulsar support contracts typically run $24,000–72,000 a year, depending on SLA level, scope (number of clusters or nodes, and environments) and deployment (self-managed, cloud-managed or Kubernetes).
| What moves the price | How it changes the contract |
|---|---|
| SLA level | Business-hours cover costs less than 24/7 cover with a 15-minute emergency response. |
| Scope | More clusters or nodes, and more environments, make a larger contract. |
| Deployment | Self-managed, cloud-managed and Kubernetes estates need different amounts of hands-on work. |
Covering several technologies under one contract, for example RabbitMQ, Kafka and Redis, earns an aggressive discount.
Support In Practice
Apache Pulsar support and remediation work from AceMQ. Each card links to the full write-up: the cluster, what AceMQ diagnosed or changed, and the result.
Global Payments Processor
Resolving cluster-wide write latency caused by bookie journal and ledger device contention, and restoring write quorum headroom.
Apache PulsarApache BookKeeper
KubernetesZooKeeperPublic Sector Agency
Diagnosing producers blocked by backlog quota enforcement when a slow or abandoned subscription prevents the backlog from clearing.
Apache PulsarApache BookKeeperKubernetesTelecommunications Operator
Sizing brokers, bookies, and metadata for a Pulsar deployment against real throughput, retention, and durability requirements.
Apache PulsarApache BookKeeperZooKeeperKubernetesManaged Services Provider
Designing tenant, namespace, and policy structure so independent teams can share a Pulsar cluster without interfering with each other.
Apache PulsarApache BookKeeperKubernetesZooKeeperSupport options
AceMQ offers Apache Pulsar support in four tiers, each handing more of the day-to-day work to AceMQ: 24/7 support and incident management for clusters your team runs, proactive monitoring that catches bookie, backlog and CVE problems first, managed Pulsar on your own infrastructure, and fully managed Pulsar on AceMQ infrastructure. Brokers, BookKeeper and the metadata store are covered in all four.
You run it, we back you up
Best for: Teams that run Pulsar themselves and need senior cover on both the broker and the storage layer.
You run it, we watch it with you
Best for: Clusters where a throttled producer or a full bookie is not an acceptable surprise.
We run it in your cloud or data centre
Best for: Regulated estates that must keep streaming data inside their own boundary.
We host it and run it, as a service
Best for: Teams that want Pulsar's multi-tenancy without running brokers, bookies and ZooKeeper.
| Who does what | Tier 1 24/7 support | Tier 2 Proactive monitoring | Tier 3 Managed, your infrastructure | Tier 4 Fully managed by AceMQ |
|---|---|---|---|---|
| Who runs Apache Pulsar day to day? | Your team | Your team, with AceMQ reviews | AceMQ | AceMQ |
| Where does it run? | Your infrastructure | Your infrastructure | Your cloud account or data centre | AceMQ infrastructure |
| 24/7 incident response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response | 15-minute P1 response |
| Health checks and CVE alerts | On request | Scheduled | Included | Included |
| Patching and upgrades | Your team, AceMQ advises | Planned with AceMQ | Done by AceMQ | Done by AceMQ |
| Monitoring and on-call | Your team | Your team | AceMQ | AceMQ |
| Data, keys and accounts | Yours | Yours | Yours | Your data, hosted by AceMQ |
Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.
One partner for Apache Pulsar
Support is one part of what AceMQ does for Apache Pulsar. The same engineers deliver consulting, health checks, migrations and end-of-life cover, and support the systems that usually run next to it.
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.
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.
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.
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.
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.
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.
Yes. AceMQ works on Apache Pulsar in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your Apache Pulsar environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Apache Pulsar is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
Reactive cover, proactive reviews, or AceMQ running Apache Pulsar for you on your infrastructure or ours. A senior engineer scopes it with you, and quote requests are answered within 1 hour.
Production incident right now?Email an Apache Pulsar Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
