Kafka vs Pulsar: System Design Trade-offs

Side by side

Dimension	Kafka	Pulsar
Storage architecture	Kafka: brokers serve and store partition replicas	Pulsar: brokers serve traffic; BookKeeper stores durable data
Scaling	Broker scaling often involves partition replica movement	Broker and storage capacity scale separately
Consumption	Consumer groups track partition offsets	Named subscriptions track acknowledgments
Ordering	Ordered within a partition	Ordering depends on partitioning and subscription type
Replay and retention	Retention is independent of consumer progress	Unacknowledged backlog plus configurable acknowledged-message retention
Multi-tenancy	ACLs and quotas; isolation needs deliberate design	Tenants, namespaces, quotas, and isolation policies
Cross-region replication	Commonly uses MirrorMaker 2 or managed tooling	Built-in asynchronous geo-replication
Operations and ecosystem	Broad connector ecosystem, Kafka Streams, and KRaft controllers	Brokers, bookies, and a metadata service; more infrastructure roles

The differences that matter

The biggest architectural difference is where durable data lives. Kafka brokers own partition replicas, so adding or replacing brokers can require moving retained data. Pulsar brokers serve topics while BookKeeper bookies store replicated ledgers. Broker ownership can move without copying the entire backlog to the new broker, but bookie replacement and storage expansion still require data-management work. Kafka tiered storage can reduce local storage pressure where supported and configured.

Kafka models consumption as positions in a log: each consumer group advances offsets independently, and records remain until retention or compaction removes them. Pulsar models consumption through named subscriptions with acknowledgments and redelivery. Shared subscriptions distribute work without preserving overall order; Key_Shared supports per-key ordered distribution subject to producer and consumer configuration. Exclusive and Failover subscriptions serve different ordering and availability needs.

Replay is not automatic just because the system is durable. Kafka consumers can rewind only while records remain available under the topic's retention and compaction policies. Pulsar retains unacknowledged subscription backlog, subject to backlog policies, but keeping acknowledged messages for later replay requires retention configuration. In either system, specify the replay window, slow-consumer policy, and storage budget.

Pulsar provides explicit tenant and namespace abstractions and built-in asynchronous geo-replication. Kafka also supports shared clusters and cross-region replication, but the isolation and replication design uses different controls and often separate tooling. Neither choice gives synchronous global ordering or automatic conflict resolution. Both still require capacity planning, regional recovery procedures, and protection against duplicate side effects.

Choose Kafka when

You need a durable event backbone with independent consumer groups, partition ordering, and a clear retention window.
Kafka Streams, Kafka Connect, or existing Kafka-compatible integrations materially reduce application work.
Your team already operates Kafka and has tested partition placement, replication, upgrades, and consumer recovery.
A broker-owned storage model meets your scaling needs, and independent serving and storage scaling is not a major requirement.

Choose Pulsar when

Serving traffic and retained backlog grow differently, making independent broker and storage scaling valuable.
One platform must support both replayable streams and acknowledgment-driven work distribution through different subscriptions.
You need explicit tenant and namespace boundaries with policies for quotas, retention, and replication.
Asynchronous cross-region replication is a core requirement, and your team can operate and troubleshoot brokers, BookKeeper, and the metadata service.

A worked example

A growing analytics backlog with stable live traffic

Assume an analytics platform ingests 50,000 events per second at an average of 1 KB each. That is about 4.32 TB per day, or 30.2 TB for seven days before replication, compression, and overhead. If live traffic stays flat but retention grows to 30 days, storage demand rises without a matching increase in serving demand. Pulsar's separate bookies let you expand storage independently of brokers. Kafka can also meet the requirement through storage expansion, partition placement, or tiered storage where available. Choose based on the deployment you can operate, then test replay alongside live consumption so historical reads do not break freshness targets.

In the interview

Start with the contract: event rate, event size, retention, consumer count, ordering scope, and acceptable data loss. Do not choose based on a generic throughput ranking.
Draw the durable write path. For Kafka, explain partition leaders, replicas, producer acknowledgments, and minimum in-sync replicas. For Pulsar, explain broker-to-BookKeeper writes and the configured write and acknowledgment quorums.
Explain how consumers recover. Discuss offset commits versus acknowledgments, redelivery after failures, poison messages, and idempotent downstream writes.
Describe one scaling event and one failure event. An interviewer may ask whether adding serving capacity moves historical data, what happens when storage nodes fail, and how a hot partition or key limits parallelism.
For multi-region designs, state replication lag, recovery-point and recovery-time objectives, and who owns writes during failover. Expect probes about duplicate delivery and ordering after a regional switch.

Common mistakes

Claiming one system is always faster. Message size, batching, durability settings, partitioning, storage, and workload shape determine performance.
Calling Pulsar stateless without qualification. Brokers maintain serving state and caches; durable data lives in BookKeeper, which still needs replication, repair, and capacity management.
Treating Kafka retention and Pulsar acknowledgments as equivalent deletion rules. Configure replay retention and slow-consumer behavior explicitly.
Claiming either system makes external side effects exactly once. Transactions and deduplication have defined boundaries; database updates, payments, and API calls still need a correctness strategy.

Where it comes up

Interview questions where choosing between Kafka and Pulsar comes up.

Questions people ask

Is Pulsar better than Kafka?

Neither is universally better. Pulsar makes serving and storage separation, subscription modes, and tenant policies central to its architecture. Kafka is often the better fit when its event-log model and ecosystem already satisfy the requirements.

Does Pulsar preserve message ordering like Kafka?

Both support ordering within a defined scope, not an automatic global order across partitions. Kafka provides partition order, but applications must preserve it during processing. Pulsar's observed ordering also depends on subscription type, key routing, redelivery, and processing concurrency.

Do Kafka and Pulsar support exactly-once processing?

Kafka supports transactions and exactly-once processing within supported Kafka workflows, including Kafka Streams. Pulsar supports transactions across topics and subscriptions, along with producer deduplication when configured. Neither automatically makes an external database write or API request exactly once; use idempotency or a coordinated integration.