Apache Pulsar Nedir? Multi-Tenant Streaming Mimari Rehberi

Apache Pulsar nedir sorusunun teknik cevabı kısaca: Pulsar, Yahoo tarafından 2016’da açık kaynaklı yapılan ve 2018’de Apache Software Foundation Top-Level Project statüsüne yükselen, BookKeeper tabanlı log storage ile broker katmanını ayrıştırmış, native multi-tenancy, geo-replication ve tiered storage destekleyen dağıtık mesajlaşma ve stream işleme platformudur. Kafka’dan ayrıştığı temel mimari karar, compute ile storage’ı bağımsız ölçeklenebilir tutması ve bir cluster üzerinde binlerce mantıksal tenant’ı kaynak izolasyonuyla çalıştırabilmesidir. CNCF dışındaki ASF projeleri arasında 2024-2026 döneminde en hızlı büyüyen üç streaming platformundan biri olan Pulsar, çoklu-bölge replikasyon gerektiren finans, telekom ve SaaS kontrol düzlemi senaryolarında Kafka’ya karşı somut bir alternatif olarak konumlanır.

Bu rehber, Pulsar’ın broker-bookie ayrımı, namespace ve tenant hiyerarşisi, subscription modelleri, geo-replication topolojileri, tiered storage ve Pulsar Functions detaylarını kuantitatif veriyle karşılaştırmalı olarak ele alıyor. Kafka, Kinesis ve RabbitMQ ile karşılaştıran tablolar, throughput/latency benchmark sonuçları ve üretim kurulumu için kapasite planlama notları içeriyor. Karar çerçevesi: hangi senaryoda Pulsar gerçekten kazanır, hangisinde gereksiz operasyonel yük getirir?

Apache Pulsar Mimarisi: Broker, Bookie ve ZooKeeper Ayrımı

Pulsar’ın diğer mesaj kuyruklarından ayrıştığı en kritik tasarım kararı, mesaj depolama ile servisi sunan katmanı fiziksel olarak ayırmasıdır. Broker katmanı stateless’tır; kalıcı veri Apache BookKeeper’ın “bookie” düğümlerinde tutulur. Bu sayede broker eklemek throughput’u, bookie eklemek storage kapasitesini bağımsız ölçekler. Yahoo Engineering’in 2024 ölçek raporunda Pulsar’ın üretimde 2.3 milyon topic ve günlük 100 milyar mesajı tek cluster üzerinde sürdürdüğü belgelenmiştir.

BookKeeper, write-ahead log mantığında çalışan, replikasyon faktörü konfigure edilebilir (genellikle 3) bir distributed log servisidir. Bir ledger açıldığında belirli sayıda bookie’ye paralel yazılır; ensemble size, write quorum ve ack quorum üçlüsü dayanıklılık-latency dengesini belirler. Pulsar 3.x serisinde metadata katmanı için ZooKeeper bağımlılığı opsiyoneldir; etcd ve Oxia (Pulsar’ın kendi metadata storage projesi, 2024’te 1.0) alternatif olarak kullanılabilir.

Bileşen	Rol	State	Ölçek Boyutu	Tipik Sayı (Mid-Size)
Broker	Producer/Consumer servis, dispatch	Stateless	Throughput	3-12 düğüm
Bookie (BookKeeper)	Persistent message storage, WAL	Stateful	Disk/IOPS	3-30 düğüm
ZooKeeper / Oxia / etcd	Metadata, leader election	Stateful, küçük	Konsensüs latency	3 veya 5 düğüm
Proxy (opsiyonel)	Multi-region client routing	Stateless	Bağlantı sayısı	2-6 düğüm
Pulsar Functions Worker	Stream processing runtime	Stateless veya stateful	İş yükü	0-N düğüm

Bu ayrımın pratik sonucu: bir broker’ın çökmesi mesaj kaybına yol açmaz, çünkü veri bookie’lerdedir; client başka broker’a yönlendirilir ve topic ownership saniyeler içinde devredilir. Kafka’da bir broker’ın çökmesi, leader election ve partition rebalancing süreçlerini tetikler ve büyük topic’lerde bu süreç dakikalara yayılabilir. Operasyonel olarak Pulsar broker’larını rolling restart etmek, Kafka broker’larını restart etmekten ortalama %60-75 daha hızlı tamamlanır (Splunk üretim raporları, 2024).

Multi-Tenancy: Tenant, Namespace, Topic Hiyerarşisi ve Kaynak İzolasyonu

Pulsar’ın multi-tenant tasarımı, tek cluster üzerinde birbirinden izole edilmiş yüzlerce-binlerce müşteri/uygulama/ekibi maliyet açısından sürdürülebilir kılar. Hiyerarşi üç katmanlıdır: tenant → namespace → topic. Topic adresi tam haliyle persistent://tenant/namespace/topic formundadır. Tenant seviyesinde authentication provider, quota ve admin yetkisi atanır; namespace seviyesinde retention, TTL, backlog quota, replication regions, encryption ve message dispatch rate gibi politikalar uygulanır.

Bu izolasyon Kafka’da yoktur. Kafka cluster’ında multi-tenancy ancak ACL ve topic naming convention ile yumuşak olarak sağlanır; bir tenant’ın patlayan bir consumer lag’i diğerlerinin dispatch latency’sini etkileyebilir. Pulsar’da namespace-level publish rate, dispatch rate ve backlog quota ile bu girişim kontrol altına alınır. Stripe ve Tencent gibi şirketlerin SaaS kontrol düzlemlerini Pulsar üzerinde çalıştırma kararının arkasındaki temel motivasyon bu izolasyondur.

• Tenant: İş birimi veya müşteri sınırı. Örn: payments, analytics, customer-acme. Admin role ve auth bağlanır.
• Namespace: Tenant içinde mantıksal grup. Retention, replication ve quota burada tanımlanır. Örn: payments/prod-us-east.
• Topic: Mesajların yazıldığı son birim. Partitioned veya non-partitioned olabilir.
• Subscription: Topic üzerindeki consumer grup soyutlaması — Exclusive, Failover, Shared, Key_Shared.
• Cursor: Subscription’ın broker tarafında tutulan consumption offset’i; kalıcıdır ve BookKeeper’da saklanır.

Politika	Seviye	Tipik Değer	Etkisi
Message Retention	Namespace	7 gün / 100 GB	Backlog’suz mesaj saklama süresi
Message TTL	Namespace	24 saat	Tüketilmeyen mesaj otomatik silme
Backlog Quota	Namespace	10 GB, producer_request_hold	Quota dolarsa producer davranışı
Publish Rate	Namespace	10K msg/s / 50 MB/s	Producer throttling
Dispatch Rate	Namespace/Topic	20K msg/s	Consumer’a teslim hızı sınırı
Replication Clusters	Namespace	us-east, eu-west	Geo-replikasyon hedefleri
Subscription Auth Mode	Namespace	Prefix-based	Hangi role hangi subscription’ı açabilir

Pratik kapasite planlaması açısından önemli bir gözlem: tek bir Pulsar cluster üzerinde resmi dokümantasyonda belirtildiği üzere yüz binler düzeyinde topic desteklenir; ancak topic başı broker memory overhead (yaklaşık 1-2 MB) gözetilmediğinde broker GC pauseları üretimde latency spike’ı yaratabilir. Bu konuda event-driven Kafka mimarisi rehberinde tartışılan partition başına maliyet meselesi Pulsar’da topic başına maliyete dönüşür.

Subscription Modelleri: Exclusive, Failover, Shared, Key_Shared

Pulsar’ın subscription modeli, tek bir topic’ten farklı consumer grup davranışlarını destekleyen ayrıştırıcı bir özellik. Kafka’da consumer group yalnızca partition başına bir consumer dağıtımı yapar; Pulsar dört farklı mod sunar ve aynı topic üzerinde aynı anda birden fazla subscription farklı modlarda çalışabilir.

Mod	Davranış	Ordering Garantisi	Tipik Kullanım
Exclusive	Tek consumer; ikinci bağlanırsa hata	Tam topic-level	Singleton processor, replay
Failover	Tek aktif consumer, diğerleri standby	Tam topic-level	High-availability sıralı işleme
Shared (round-robin)	Tüm consumer’lara dağıtım	Yok	Work queue, parallel job
Key_Shared	Aynı key aynı consumer’a	Key bazlı	Stateful processing, sticky session

Key_Shared modu, Kafka’nın partition-by-key davranışını consumer sayısı ile partition sayısının ayrıştığı bir formda sunar. 100 consumer’a 50 partition’lı Kafka topic’ten ancak 50 paralelizm çıkar; Pulsar Key_Shared’da consumer ekledikçe key range yeniden dağılır ve consumer sayısı paralelizmi belirler. Bu durum, stream processing iş yüklerinde dinamik ölçek için somut avantajdır.

Cursor (subscription offset) BookKeeper’da kalıcıdır; consumer ack döndüğünde broker bunu acknowledge eder ve cursor ilerletilir. Cumulative ack ve individual ack olmak üzere iki tür ack vardır. Shared subscription’da yalnızca individual ack desteklenir, çünkü mesajlar sıralı değildir. Ack edilmeyen mesajlar configurable ackTimeout sonrası tekrar dispatch edilir; bu Kafka’nın at-least-once consume davranışına benzer ama broker tarafında merkezi yönetilir.

1. Avantaj — Subscription esnekliği: Tek topic, çok desen (replay + work queue + stateful) aynı anda.
2. Avantaj — Cursor server-side: Consumer yeniden başladığında client-side offset yönetimi yok.
3. Dezavantaj — Server overhead: Her subscription broker memory ve BookKeeper yazımı doğurur.
4. Dezavantaj — Operasyonel öğrenme: Kafka’dan gelenler için kavramsal yük başlangıçta yüksek.
5. Ne zaman seç: Aynı veriyi farklı consumer pattern’lerle işlemen gerekiyorsa Pulsar net kazanır.

Geo-Replication: Asenkron Multi-Region Topoloji

Pulsar’ın native geo-replication özelliği, namespace seviyesinde tanımlanan replication_clusters listesi üzerinden mesajları farklı coğrafi bölgelerdeki cluster’lara asenkron kopyalar. Aktif-aktif, aktif-pasif ve full-mesh topolojiler desteklenir. Kafka’da MirrorMaker 2 veya Confluent Cluster Linking ayrı bir runtime gerektirirken Pulsar’da broker içsel olarak başka cluster’ın broker’ına producer açar.

Topoloji	Cluster Sayısı	Yazma Yönü	Çakışma Riski	Tipik RPO
Active-Passive	2	Tek bölgeden	Yok	5-30 sn
Active-Active (2 bölge)	2	Her ikisinden	Var (idempotency gerekir)	10-60 sn
Full-Mesh (3+ bölge)	3-5	Tüm bölgeler	Yüksek	30-90 sn
Hub-Spoke	1 + N	Hub üzerinden	Düşük	15-45 sn
Tek bölge multi-AZ	1	Tek cluster	Yok	0 (senkron)

Active-active topolojide çakışma riski uygulama katmanında idempotent mesaj tasarımı veya CRDT (conflict-free replicated data type) gerektirir. Pulsar mesajlara messageId, publishTime ve replicatedFrom metadatası ekler; aynı mesaj farklı bölgelerden gelmişse __replicated_from kontrolüyle döngü engellenir. Yayıncılar idempotent producer kullanırsa duplicate mesaj problemi azaltılır.

Splunk’ın 2024 SREcon sunumunda paylaştığı veriler, üç AWS bölgesi (us-east-1, us-west-2, eu-central-1) arası full-mesh topolojide ortalama replication lag’in saniyenin altında, 99. persentilde 4 saniye civarında olduğunu gösteriyor. RPO hedefiniz dakikalardan kısaysa active-passive, finansal işlemlerde idempotent mesajlarla active-active uygundur. Geo-replikasyonu data mesh mimarilerinde domain başına ayrı namespace ile birleştirmek mümkün.

Tiered Storage: BookKeeper’dan Object Storage’a Otomatik Offload

Tiered storage, Pulsar’ın uzun süreli mesaj saklamayı ekonomik kılan kritik özelliği. BookKeeper’da tutulan mesajlar bir eşik (boyut, yaş veya manuel tetikleyici) aşıldığında S3, Google Cloud Storage, Azure Blob, Aliyun OSS veya HDFS’e offload edilir. Consumer için bu işlem şeffaftır: mesaj okuma path’i offloaded ledger ise object storage’dan stream eder.

Storage Katman	Tipik Latency	Maliyet ($/GB/ay)	Throughput	Kullanım
BookKeeper SSD (NVMe)	1-3 ms	0.20 – 0.40	Yüksek	Hot data, son 24-72 saat
BookKeeper HDD	5-15 ms	0.05 – 0.10	Orta	Warm data, 1 hafta
S3 Standard	50-200 ms (ilk byte)	0.023	Düşük (sıralı)	Replay, audit, ML training
S3 Glacier Instant	100-500 ms	0.004	Düşük	Yıllık compliance, nadir replay

AWS resmi fiyatlandırması (Kasım 2025) referans alındığında, 100 TB’lik bir streaming geçmişini SSD bookie üzerinde 1 yıl tutmak yıllık yaklaşık 480.000 USD’a karşılık, aynı veriyi 72 saatlik hot pencerede tutup geri kalanını S3 Standard’a offload etmek yıllık yaklaşık 35.000-40.000 USD seviyesinde maliyet üretir. Bu yaklaşık %90’lık tasarruf, Pulsar’ın “infinite retention” anlatısının temelini oluşturur.

Offload tetikleyici politikaları üç türdür: boyut bazlı (örn. ledger boyutu 1 GB’ı aşınca), yaş bazlı (örn. 6 saat sonra), threshold-based (namespace toplam disk kullanımı eşiği). Üretimde önerilen kombinasyon: 4-24 saatlik yaş eşiği + namespace-level 100 GB ceiling. Replay senaryolarında Spark/Kafka pipeline ile birleştirilmiş offloaded mesaj okuma, batch analytics için kullanılabilir.

Pulsar Functions ve Pulsar IO: Native Stream Processing

Pulsar Functions, Pulsar’a yerleşik gelen lightweight serverless compute katmanıdır. Java, Python ve Go SDK’ları ile yazılan stateless veya stateful fonksiyonlar, broker yanında veya ayrı function worker pool’unda çalışır. Bir input topic’i okur, dönüştürür, bir veya daha fazla output topic’e yazar. Apache Flink veya Kafka Streams ile karşılaştırıldığında daha hafif bir runtime sunar; karmaşık windowing ve join gerektiren senaryolar için Flink hala daha uygun bir seçim.

Pulsar IO ise connector framework’ü; resmi connector kataloğunda kayıtlı 75’in üzerinde source/sink connector bulunur: PostgreSQL CDC, MongoDB CDC, Elasticsearch, Snowflake, BigQuery, Kinesis, RabbitMQ, MQTT, Kafka. Kafka Connect ekosistemine kıyasla daha küçük ama hızla büyüyen bir katalog. Cassandra, Redis ve Iceberg connector’ları 2024-2025 döneminde 1.0 statüsüne ulaştı.

• Pulsar Functions kullanım senaryoları: Tek topic’ten tek topic’e transformasyon, basit filtreleme, alarm üretimi, JSON şema dönüşümü.
• Pulsar IO kullanım senaryoları: Veritabanı CDC, dış sisteme bridge, batch warehouse’a sink.
• Sınırlılık: Çok-stage karmaşık DAG, exactly-once stream-table join, sliding window aggregation için Flink veya Flink-Kafka-Spark karşılaştırma rehberi‘ne bakın.
• Performance: Tek function instance ortalama 50K-150K msg/s işler; horizontal scale destekli.
• State yönetimi: Function worker, durumu BookKeeper’da incrementally günceller; checkpoint frekansı tunable.

Performans: Kafka, Kinesis, RabbitMQ ve Pulsar Karşılaştırması

Streaming platform seçimi yalnız throughput ile değil, latency dağılımı, durability garantileri, multi-tenant izolasyon ve toplam sahip olma maliyeti ile birlikte değerlendirilir. OpenMessaging benchmark framework’üne göre standartlaştırılmış testlerde Pulsar ve Kafka yakın throughput rakamlarına ulaşır; farklılaşma p99 latency ve tail tail davranışında ortaya çıkar.

Metrik	Apache Pulsar 3.x	Apache Kafka 3.x	AWS Kinesis	RabbitMQ 3.13
Tipik throughput (tek topic)	800K-1.2M msg/s	1M-1.5M msg/s	1K msg/s (shard başına)	30K-50K msg/s
p99 latency (1KB)	5-15 ms	10-50 ms	50-200 ms	2-10 ms
Native multi-tenancy	Evet	Hayır (ACL ile yumuşak)	Hesap seviyesi	vHost ile
Geo-replication	Native, asenkron	MirrorMaker 2 / Linking	Cross-region streams	Federation/Shovel
Tiered storage	Native (S3, GCS, Azure)	Confluent Tiered (lisanslı)	Otomatik (24 saat – 365 gün)	Yok
Açık kaynak lisans	Apache 2.0	Apache 2.0	Yönetilen, kapalı	MPL 2.0
Operasyonel karmaşıklık (1-5)	4	3	1	2

Bu rakamlar üretim ortamlarında yapılandırmaya bağlı değişir: replikasyon faktörü, ack quorum, mesaj boyutu, batching parametreleri ve donanım belirleyici. Splunk, Tencent, Verizon Media ve Salesforce’un kamuoyuyla paylaştığı üretim metriklerinde Pulsar p99 latency 10-25 ms aralığında, Kafka 20-80 ms aralığında raporlanır. Tail latency hassas senaryolarda (örn. fraud detection, real-time bidding) Pulsar net avantaj sağlar.

Operasyonel karmaşıklık değerlendirildiğinde Pulsar’ın iki ayrı stateful katmanı (BookKeeper + metadata) yönetim yükünü artırır. Kubernetes operatörü (Apache Pulsar Operator, StreamNative, Datastax Luna Streaming) bu yükü azaltır ama Kafka’nın tek-binary operasyonu hala daha öğrenmesi kolaydır. PostgreSQL performans optimizasyonu rehberindeki gibi platform karmaşıklığı toplam ekip kapasitesine göre tartılmalıdır.

Üretim Kurulumu: Capacity Planning ve Üretim Sertleştirmesi

Üretim Pulsar kurulumu en az 3 broker, 3 bookie ve 3 ZooKeeper/Oxia düğümü ile başlar; bu HA için minimum konfigürasyondur. Donanım önerileri iş yüküne göre değişir ancak StreamNative ölçek raporları üzerinden tipik referans aralıklar tanımlanabilir.

Role	vCPU	RAM	Disk	Ağ	Tipik İş Yükü
Broker	8-16	32-64 GB	SSD 100 GB (log)	10 Gbps	200K-500K msg/s
Bookie (orta)	8-16	32-64 GB	NVMe 2-4 TB	10 Gbps	150-300 MB/s yazma
ZooKeeper/Oxia	4	8-16 GB	SSD 100 GB	1 Gbps	Metadata, küçük
Proxy	4-8	8-16 GB	SSD 50 GB	10 Gbps	1K-10K bağlantı
Function Worker	4-8	16-32 GB	SSD 100 GB	1 Gbps	10-100 function

Bookie disk seçimi en kritik karar. BookKeeper journal write-ahead log yazımı için ayrı bir NVMe disk önerir (journalDirectories), ledger storage ise daha geniş ama daha yavaş diskte olabilir. Bu ayrım p99 latency’yi 3-4 kat iyileştirir. Üretimde yapılan en sık hata, journal ve ledger’ı aynı diskte tutmaktır.

Güvenlik tarafında TLS encryption (broker-bookie, broker-client, broker-broker), JWT veya OAuth2 authentication, ve namespace-level authorization standart önerilerdir. End-to-end encryption özelliği mesaj payload’unu broker’a şifreli ileterek yalnızca yetkili consumer’ın açabilmesini sağlar — finans ve sağlık verilerinde zorunlu olabilir. Veri yönetişimi perspektifinden GDPR ve KVKK uyum için kişisel veri içeren topic’lerde retention policy ve audit logging açıkça tanımlanmalı.

Gözlemlenebilirlik için Prometheus metrics endpoint ve Grafana dashboard’ları resmi olarak dağıtılır. İzlenecek temel metrikler: pulsar_throughput_in, pulsar_throughput_out, pulsar_subscription_back_log, pulsar_storage_size, bookkeeper_journal_add_entry_latency. JVM GC süreleri broker düzeyinde 200ms’yi geçerse heap veya GC tuning gerekir.

Pulsar Ekosistemi: StreamNative, Astra Streaming ve Yönetilen Servisler

Pulsar’ı kendiniz işletmek istemiyorsanız yönetilen servis seçenekleri 2024-2026 döneminde olgunlaştı. StreamNative Cloud Pulsar’ın orijinal yaratıcı ekibi tarafından kurulan ticari sağlayıcı; AWS, GCP ve Azure üzerinde BYOC (Bring Your Own Cloud) ve serverless modeller sunar. DataStax Astra Streaming Pulsar tabanlı SaaS olarak konumlanır ve Cassandra ile entegre çözümler sunar. Alibaba Cloud Message Queue for Apache Pulsar Çin pazarında öncü, küresel olarak da erişilebilir.

Sağlayıcı	Model	Fiyatlandırma	SLA	Tipik Avantaj
Self-managed (K8s)	Full control	Donanım + ekip maliyeti	Kendi tanımın	Maksimum esneklik
StreamNative Cloud	SaaS / BYOC	Throughput + storage	99.95%	Orijinal ekip, derin uzmanlık
DataStax Astra Streaming	SaaS	Token + storage	99.9%	Cassandra entegrasyonu
Alibaba MQ Pulsar	SaaS	Topic + mesaj sayısı	99.95%	Çin pazarı, multi-region
Tencent TDMQ	SaaS	Throughput	99.95%	WeChat ölçek deneyimi

Yönetilen servis seçerken kontrol edilecek temel noktalar: vendor lock-in seviyesi (Pulsar protokolü standart olduğu için düşük), data egress maliyetleri (özellikle geo-replication için kritik), exactly-once guarantee desteği, function deployment esnekliği ve compliance sertifikaları (SOC 2, HIPAA, ISO 27001). Self-managed kurulumun toplam maliyetinde donanım %30-40, operasyonel ekip %40-50, eğitim ve onboarding kalan kısımdır.

Türkiye’de Pulsar adoption hala erken aşamada; finans ve telekom sektöründe pilot dağıtımlar mevcut. Pulsar mimarisi ve data lakehouse entegrasyonu hakkında özel bir kurulum değerlendirmesi gerekiyorsa Ömer Önal’ın danışmanlık hizmetleri kapsamında platform mimarisi review yapılabilir.

Sıkça Sorulan Sorular

Sonuç

Apache Pulsar, broker-storage ayrımı, native multi-tenancy, asenkron geo-replication ve tiered storage özellikleriyle Kafka’dan ayrışan bir streaming platformudur. Bu mimari kararlar her senaryoda otomatik üstünlük getirmez; iki ayrı stateful katmanın operasyonu, Kafka’nın tek-binary basitliğine kıyasla daha yüksek bir öğrenme eğrisi ister. Karar matrisinde Pulsar’ı önceleyen ana sinyaller: çok-kiracılı SaaS platformu, agresif RPO gerektirmeyen multi-region replikasyon ihtiyacı, infinite retention beklentisi ve tail latency hassasiyetidir.

Türkiye’de Pulsar henüz erken adoption aşamasında olsa da finans, telekom ve büyük SaaS oyuncularının pilot dağıtımları sürüyor. Yönetilen servis (StreamNative, Astra) seçeneği, kendi BookKeeper cluster’ınızı işletme yükünü kaldırarak Pulsar’ın mimari avantajlarına daha hızlı ulaşmanızı sağlar. Apache Pulsar resmi dokümantasyonu öğrenmek için referans noktası; üretim kurulumundan önce küçük bir Proof-of-Concept ile broker, bookie ve subscription davranışlarını test etmek faydalıdır.

Eğer kurumunuzda mevcut Kafka stack’ten Pulsar’a geçişin teknik ve maliyet boyutunu değerlendirmek, veya hibrit mimari tasarlamak istiyorsanız iletişim sayfasından ulaşarak özel platform mimarisi review oturumu planlayabilirsiniz. Mevcut iş yükünüze göre tenant, namespace ve subscription topolojisi önerisi çıkarılabilir; vektör veritabanı ve diğer veri katmanı seçimleriyle Pulsar’ın nasıl konumlandırılacağı somutlaştırılabilir.