What is the fundamental architectural difference between how Apache Pulsar and Apache Kafka store and serve data?

**The core question is: where does the data live, and who serves it?** **Kafka (single-tier / coupled compute+storage).** A Kafka cluster is a set of *brokers*. A topic is split into *partitions*; each partition is an append-only log file. Every partition has a *leader broker* that owns the authoritative copy on that broker's local disk, plus *follower* replicas on other brokers. Producers and consumers talk to the leader broker, and that same broker reads/writes the log from its own disk. So in Kafka a broker is simultaneously the compute (serving) node and the storage node for its partitions. Consequences: (1) to grow storage you add brokers and rebalance partitions, which physically copies log segments across the network; (2) a broker failure means its partitions must elect a new leader among replicas that already hold copies; (3) compute and storage capacity are bought together even if you only need one. **Pulsar (two-tier / disaggregated).** Pulsar splits the two jobs: - **Brokers** are *stateless* serving nodes. They accept producer writes and feed consumers, manage subscriptions and dispatching, but keep **no** topic data on local disk. - **Apache BookKeeper** is the storage tier. It is a distributed, low-latency write-ahead log service whose nodes are called **bookies**. The unit of storage is a **ledger** (an append-only sequence of entries). A broker writes incoming messages to a ledger spread across several bookies. - **Metadata** (which broker owns which topic, ledger locations, cursors) lives in ZooKeeper (older) or etcd. Because a Pulsar broker stores nothing, you can: kill a broker and have another broker pick up its topics in milliseconds (no data copy — the data is in BookKeeper already); add brokers purely to add serving throughput; add bookies purely to add storage/IO. This is the classic *separation of compute and storage* benefit. **Trade-offs.** Pulsar's design adds an extra network hop (client → broker → bookies) and more components to operate (brokers, bookies, metadata store, plus a function worker if you use Pulsar Functions). Kafka's tighter coupling means fewer hops and a simpler ops surface, at the price of expensive partition rebalancing and tying storage growth to broker growth. Modern Kafka has narrowed the gap with **tiered storage (KIP-405)** which offloads cold segments to object storage, but the *hot* path remains broker-local; it is not full storage disaggregation like Pulsar's. **Edge cases to know.** A Pulsar broker failure is cheap (stateless), but a *bookie* failure triggers BookKeeper's auto-recovery/re-replication to restore the configured replication. In Kafka, the analogous event is under-replicated partitions and leader re-election. Also, Pulsar's two tiers can be scaled in the wrong direction relative to your bottleneck (e.g. adding brokers when bookies are the IO bottleneck), so you must know which tier is saturated.