> Почему Pulsar не может достичь такого же уровня масштабируемости как Kafka (Go)

Короткий ответ

Pulsar и Kafka имеют принципиально разные архитектуры хранения: Kafka использует локальные диски брокеров, а Pulsar - отдельный слой bookies (Apache BookKeeper). Масштабируемость Kafka ограничена репликацией и партиционированием на уровне брокеров, тогда как Pulsar разделяет compute и storage, что позволяет масштабировать их независимо. Однако на практике Pulsar уступает Kafka в пропускной способности на один брокер из-за дополнительного сетевого hop и накладных расходов на запись в BookKeeper.

Подробное объяснение

Ключевое различие - в модели хранения и репликации.

Kafka: каждый брокер хранит партиции на локальных дисках. Репликация - это копирование логов между брокерами через fetch-запросы. Масштабирование достигается добавлением брокеров и перераспределением партиций. Ограничения:

• партиция привязана к конкретному брокеру, её размер ограничен диском этого брокера;
• ребалансировка при добавлении брокера - долгая операция, требующая копирования данных;
• рост числа партиций увеличивает overhead на фоновые операции (replication, metadata sync).

Pulsar: данные пишутся в BookKeeper - распределённое журналируемое хранилище. Брокеры Pulsar не хранят данные, они лишь управляют метаданными и обслуживают клиентские подключения. Bookies образуют отдельный кластер, который горизонтально масштабируется независимо. Это даёт:

• эластичное масштабирование storage без ребалансировки партиций;
• возможность добавлять брокеры без перемещения данных;
• отдельное масштабирование чтения и записи.

Почему же Pulsar не достигает уровня Kafka по масштабируемости в бенчмарках:

1. Сетевой overhead: каждая запись идёт от producer → брокер → bookie (и реплики bookies). Kafka пишет на локальный диск, что быстрее.

2. Задержки подтверждения: Kafka подтверждает запись после fsync на всех in-sync replicas. Pulsar - после записи в кворум bookies, что требует больше сетевых round-trips.

3. Пропускная способность на брокер: брокер Pulsar - это прокси, он не использует page cache напрямую, в отличие от Kafka, где чтение идёт из кэша ОС.

4. Сложность операций: BookKeeper требует отдельной настройки, мониторинга и тюнинга. При неправильной конфигурации (например, недостаточное число bookies) производительность резко падает.

5. Протокол репликации: Kafka использует простой leader-follower с fetch-based репликацией, что эффективно для последовательных логов. BookKeeper использует quorum-based запись (write to N/2+1), что даёт больше latency при малых кластерах.

Однако важно уточнить: Pulsar масштабируется лучше в сценариях с очень большим числом партиций и длительным хранением данных, потому что storage отделён. Kafka упирается в лимиты дисков брокеров. Но в типичных нагрузках (высокий throughput, умеренное число партиций) Kafka выигрывает.

На практике

Для senior-позиции важно показать понимание trade-off, а не просто заученные факты. Практические следствия:

• если нужен максимальный throughput на кластер при фиксированном числе брокеров - Kafka;
• если нужна эластичность storage и многотемность с тысячами партиций - Pulsar;
• если важна мультитенантность и изоляция - Pulsar из коробки;
• если команда уже умеет эксплуатировать Kafka - переход на Pulsar не даст выигрыша без явной потребности.

Также стоит упомянуть, что современные версии Kafka (3.x+) улучшили масштабируемость через KRaft (убрали ZooKeeper), но архитектурное ограничение локального хранения осталось.

Пример кода

Пример не требуется, так как вопрос концептуальный. Но можно упомянуть, что в Go-проектах выбор драйвера (franz-go для Kafka, pulsar-client-go для Pulsar) не влияет на архитектурные ограничения.

Как отвечать на собеседовании

1. Начни с короткого тезиса: "разные архитектуры хранения".
2. Объясни разницу: локальные диски vs отдельный storage слой.
3. Перечисли конкретные причины: сетевой hop, quorum writes, отсутствие page cache.
4. Уточни, что масштабируемость - это не только throughput, но и эластичность, число партиций, операционная сложность.
5. Приведи пример, когда Pulsar объективно лучше (много партиций, долгое хранение).
6. Заверши выводом: "Kafka выигрывает в throughput на брокер, Pulsar - в гибкости масштабирования storage".

Что проверяет интервьюер

• понимание внутреннего устройства обоих систем;
• способность сравнивать не по маркетинговым заявлениям, а по архитектуре;
• умение видеть trade-off, а не искать "лучшую" систему;
• знание практических ограничений (сетевые задержки, quorum, page cache);
• способность объяснить сложное простыми словами.

Типичные ошибки

• утверждение "Pulsar вообще не масштабируется" - неверно, он масштабируется иначе;
• игнорирование роли BookKeeper - без него ответ неполный;
• сравнение только по throughput, без учёта числа партиций и хранения;
• забыть про сетевой overhead и quorum writes как ключевые причины;
• утверждение, что Kafka не имеет ограничений - это тоже ошибка, ограничения есть, просто другие.