Apache Pulsar Overview

By Kokil Thapa | Last reviewed: September 2026

Your checkout service publishes an order event. A warehouse worker needs a queue. Analytics needs a stream. Email needs its own copy. You do not want three brokers and three ops runbooks. An Apache Pulsar overview starts here: one platform that treats queuing and streaming as the same primitive. Pulsar separates compute from storage, ships multi-tenancy by design, and fits teams building event-driven APIs beside traditional web stacks. This guide maps architecture, trade-offs against Kafka, and practical integration paths for PHP and Laravel shops.

What is Apache Pulsar and how does its architecture work?

Apache Pulsar is an open-source, distributed pub-sub messaging system originally built at Yahoo and now maintained under the Apache Software Foundation. Unlike brokers that store messages on local disk, Pulsar splits responsibilities: stateless brokers handle protocol and routing, while Apache BookKeeper (Bookies) persists log segments. That split lets you scale reads and writes independently.

In practice, this matters when traffic spikes during a sale or a payment-gateway webhook burst. You add brokers for connection load. You add Bookies when retention or throughput outgrows disk I/O. Metadata (namespaces, policies, ownership) lives in a coordination service—historically Apache ZooKeeper, increasingly etcd or the bundled metadata store depending on deployment mode.

Core concepts you must understand

Pulsar organises data in a hierarchy: tenant → namespace → topic. A topic is either persistent (durable, replayable) or non-persistent (fire-and-forget). Producers publish to a topic. Consumers attach through a subscription, which defines delivery semantics.

• Exclusive — one consumer per subscription; classic queue behaviour.
• Shared — messages round-robin across consumers in the same subscription.
• Failover — one active consumer; others stand by for HA.
• Key_Shared — partition by message key; useful for order-per-customer workflows.

That model is the heart of any Apache Pulsar overview. The same topic can feed a streaming analytics subscription and a competing-consumer warehouse queue without duplicating storage. Retention, TTL, deduplication, and delayed delivery are namespace policies—not one-off broker hacks.

Message lifecycle in one pass

1. A producer sends a message to a topic partition managed by a broker.
2. The broker writes the entry to BookKeeper and assigns a ledger offset.
3. Consumers on active subscriptions receive messages according to their type.
4. Acknowledgements remove cursor progress; unacked messages can be redelivered.
5. Retention policies purge old ledgers once cursors and time limits allow.

For teams used to Apache Kafka fundamentals, think of ledgers as segmented, replicated logs. Cursors resemble consumer offsets, but Pulsar tracks them per subscription natively.

How does Apache Pulsar compare to Apache Kafka?

Both systems move high-volume events between services. Kafka excels as a commit log with a mature ecosystem. Pulsar targets organisations that need multi-tenancy, unified queue-plus-stream semantics, and independent storage scaling from day one. Neither replaces a relational database; both sit in the async integration layer beside your enterprise application tier.

On a production Laravel application, I have seen Kafka chosen simply because the team already ran it. Pulsar wins when one platform must serve product analytics, background jobs, and partner webhooks with strict isolation between business units. Budget-sensitive Nepal teams should weigh managed service availability and local ops skill before committing either way.

When should you choose Apache Pulsar for your stack?

Pulsar earns its place when event volume, tenant count, or replication requirements outgrow a single-team Kafka cluster. It also fits platforms mixing real-time streams with job-queue semantics—booking confirmations, payment callbacks, and inventory updates on one bus.

A trekking booking system like Adventure Third Pole Trek might emit booking.created, payment.captured, and supplier.notified events. Analytics wants the full stream. Fulfillment workers need competing consumers. Email wants isolated retry. Pulsar avoids cloning topics or building bridge services.

Strong fit signals

• Multiple business units share infrastructure but need hard isolation.
• You require geo-replicated topics between Kathmandu and a foreign cloud region.
• Retention spans days for ops queues and months for compliance streams on the same data.
• You plan Pulsar Functions or connectors instead of maintaining separate stream processors.
• Ops can run BookKeeper plus brokers, or buy a managed Pulsar offering.

Weak fit signals

• A small monolith with Laravel queues and Redis already meets SLA.
• Your team lacks time to learn BookKeeper tuning and ledger recovery.
• You need the deepest PHP-native client libraries today—Kafka may be simpler.
• Message volume is low; Postgres NOTIFY or Redis pub-sub suffices.

Payment-heavy platforms should also read how Nepal's digital payment landscape in 2026 drives webhook volume. Gateways like eSewa and Khalti send retries and delayed confirmations. A durable log with explicit redelivery beats losing callbacks in memory.

How do you integrate Apache Pulsar with PHP and Laravel applications?

Laravel 13 on PHP 8.3+ remains the default stack on many projects I maintain. Pulsar does not ship a first-party Laravel driver. Integration paths are still straightforward if you treat Pulsar as infrastructure behind your custom software boundary.

Pattern A: HTTP produce via Pulsar REST admin/produce APIs

Your web tier publishes JSON events over HTTPS to a Pulsar HTTP gateway or reverse proxy. Validate payloads with Form Requests, then fire-and-forget with Guzzle. Keep payloads small; use a JSON formatter in dev to catch schema drift early.

// app/Services/OrderEventPublisher.php (conceptual)
public function publishOrderCreated(Order $order): void
{
    $payload = [
        'event' => 'order.created',
        'id' => $order->uuid,
        'total' => $order->total,
        'occurred_at' => now()->toIso8601String(),
    ];

    Http::timeout(2)
        ->post(config('pulsar.produce_url'), $payload)
        ->throw();
}

Pattern B: Outbox table + dedicated consumer worker

Write events to an outbox table in the same DB transaction as the business row. A sidecar worker (Python, Go, or Java—common in Pulsar ops) reads the outbox and publishes to Pulsar. Laravel queues can drain the outbox locally if you are not ready for a full broker yet. This pattern survives web request timeouts and gives you an audit trail.

Pattern C: Consumer as a long-running Artisan command or supervisor job

Use the official Java or Python client in a microservice. Laravel consumes results via internal HTTP or by writing to Redis/DB. Avoid blocking PHP-FPM workers on long-lived Pulsar consumer loops; Apache + PHP-FPM is the wrong place for perpetual socket reads.

Apply the same rate limiting and abuse prevention mindset to inbound webhook endpoints that later publish to Pulsar. Validate signatures first, then enqueue.

How do you deploy and operate Apache Pulsar in production?

Pulsar ops are not Laravel deploys. You need JVM tuning, BookKeeper disk planning, and metadata backups. Teams running Ubuntu 22/24 with Apache and PHP-FPM for the web tier often host Pulsar on separate nodes—or use StreamNative, DataStax Luna, or cloud vendor offerings.

Minimal production checklist

1. Run at least three Bookies on SSD with dedicated journal and ledger disks where possible.
2. Run three or more brokers behind a load balancer for the binary protocol and HTTP ports.
3. Secure metadata (ZooKeeper or etcd) with auth and regular snapshots.
4. Enable TLS and token auth before exposing brokers beyond a private VPC.
5. Configure namespace retention, backlog quotas, and monitoring from day one.
6. Document restore drills: ledger corruption recovery is a BookKeeper skill, not a Google search on deploy day.

Pair Pulsar metrics with the same observability mindset as Prometheus and Alertmanager alerting. Track publish latency, storage size, consumer backlog, and under-replicated ledgers. Alert on backlog growth before customers notice delayed emails or stale dashboards.

For multi-region setups, compare Pulsar geo-replication against broader active-active versus active-passive multi-cloud strategies. Pulsar replication handles topic fan-out between clusters; it does not replace DNS failover or database conflict resolution in your Laravel app.

On shared EC2-style infrastructure, I have maintained legal-tech and translation portals with Deployer 7 and GitLab CI. Message brokers live on separate instance groups with stricter firewall rules. UFW allows broker ports only from application subnets. That separation matches how Translation Nepal and sister sites isolate public HTTP from internal services.

Local development with Docker

The official standalone container suits feature branches—not load tests. Start it, create a tenant, and point your publisher worker at pulsar://localhost:6650.

docker run -it -p 6650:6650 -p 8080:8080 \
  apachepulsar/pulsar:latest bin/pulsar standalone

bin/pulsar-admin tenants create acme
bin/pulsar-admin namespaces create acme/orders
bin/pulsar-admin topics create persistent://acme/orders/order-events

Validate message schemas in CI. A broken JSON field should fail a test, not poison a consumer loop at 2 a.m. Tools like a regex tester help lock down log parsing rules when debugging broker logs locally.

Cost and staffing reality for Nepal teams

Self-hosting three production-grade nodes on a cloud provider might run Rs 25,000–45,000/month (~USD 185–335) before storage growth. Managed Pulsar reduces ops load but raises subscription cost. A five-person agency rarely needs Pulsar on day one; Redis queues and Horizon cover most eCommerce order flows until cross-service events explode.

When you outgrow that stage, budget for Linux system administration or managed services. Broker upgrades and BookKeeper rolling restarts are not optional side tasks.

What advanced features matter in a complete Apache Pulsar overview?

Beyond basics, four features separate Pulsar from "yet another log."

Pulsar Functions and IO connectors

Pulsar Functions run lightweight transforms on messages without standing up Flink or Spark for simple maps and filters. Pulsar IO connectors sync topics with external systems—Kafka, RabbitMQ, MongoDB, PostgreSQL CDC depending on your connector pack. Use them to reduce bespoke glue code, but keep business rules that touch money or legal consent in your Laravel domain layer.

Tiered storage and offloading

Old ledgers can offload to S3-compatible object storage. Hot data stays on Bookies; cold replay still works. That matters for audit logs on client portals with document history where retention is measured in years, not hours.

Schema registry and compatibility

Pulsar supports Avro, JSON, and Protobuf schemas with compatibility policies. Enforce backward compatibility when mobile apps and partner APIs consume the same topic. Breaking schema changes should fail CI, not midnight consumers.

Delayed and scheduled delivery

Native delayed messaging supports reminder emails, retry backoff, and scheduled report generation without cron scanning entire tables. Still idempotent on the consumer side—duplicates happen whenever acks race with redelivery.

Teams exploring automation pipelines often pair event buses with AI integration workflows. Publish document.uploaded events; a worker calls an LLM API; results land in a review queue. Pulsar keeps the handoff decoupled from PHP request timeouts.

Key Takeaways

• Apache Pulsar separates broker compute from BookKeeper storage, so you scale messaging without monolithic broker disks.
• Subscriptions turn one topic into both a stream and a queue—core to any Apache Pulsar overview.
• Choose Pulsar for multi-tenancy, geo-replication, and unified semantics; stay on Redis or Kafka when ops maturity or PHP tooling favours simplicity.
• Integrate Laravel via outbox tables and sidecar publishers—not long-lived consumers inside PHP-FPM.
• Plan monitoring, TLS, retention, and BookKeeper recovery before production traffic—not after the first backlog incident.
• Match broker investment to real event volume; most SMB sites should exhaust Laravel queues first.

People Also Ask

Is Apache Pulsar better than Kafka?

Neither is universally better. Kafka leads on ecosystem size and managed options. Pulsar leads when one cluster must serve multiple tenants, replicate geographically, and mix queue-style shared subscriptions with streaming readers on identical topics. Your team's existing skills often decide the winner.

What language clients does Pulsar support?

Official clients exist for Java, C++, Python, Go, and Node.js. PHP lacks a mature official client, so Laravel teams typically publish through HTTP gateways, sidecar services, or the outbox pattern rather than embedding a native consumer in the web tier.

Can Apache Pulsar replace RabbitMQ or Redis queues?

It can replace them at scale, but often should not at small scale. Redis with Laravel Horizon remains cheaper and simpler for single-app background jobs. Pulsar fits when many services, regions, or teams share durable events with strict isolation.

Who uses Apache Pulsar in production?

Yahoo, Tencent, Verizon Media, and numerous finance and IoT platforms have public Pulsar stories. Adoption is smaller than Kafka's but strong where multi-tenancy and storage scaling were design requirements from the start.

Build event-driven systems with the right messaging layer

This Apache Pulsar overview is a map, not a mandate. Most web products still ship faster on Laravel queues, Redis, and clear domain boundaries. When events cross teams, regions, or compliance boundaries, Pulsar's unified model earns a serious look. Start with one namespace, one topic, and an outbox publisher; measure backlog and latency before you split clusters.

If you are designing async architecture for a booking platform, legal portal, or payment-heavy store and want a second opinion on Pulsar versus Kafka versus staying on Redis, contact us for an architecture review. You can also browse production portfolio work, read about infrastructure migrations, or explore ongoing support and maintenance for systems already in production.