The Power of Apache Pulsar. Harnessing Dapr to Build High Scale Messaging
summary
FICO migrates eventing from Kafka to Apache Pulsar using Dapr and StreamNative operators, claiming better scalability because Pulsar separates storage from brokers, plus Kafka wire-protocol compatibility so existing clients run unchanged. Dapr becomes an abstraction layer with a sidecar model; community work adds schema, OIDC, and pluggable auth within a year while transactions arrive only after Pulsar 3.2. Benchmarks show low overhead—Dapr sidecar uses 48 MB and ~5–10% CPU—and metering buffers five records as a tunable durability/efficiency tradeoff. Kafka-compatible APIs run on Pulsar and transactional migration is ongoing.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 3:53Siloed point solutions challenges
- 7:10Business to services decomposition
- 10:24Event broker software requirements
- 13:34FICO chose Apache Pulsar
- 16:25Reasons for StreamNative Pulsar
- 19:12Need for Dapr abstraction
- 22:00What is Dapr
- 24:47Dapr gaps for Pulsar
- 26:53Dapr performance and transactions
- 28:42Pulsar migration strategy
- 30:25Scaling Dapr with Diagrid
related talks
46mScalable messaging and streaming with Apache Pulsar
45mApache Pulsar: Finally an Alternative to Kafka?
45mScalable distributed messaging&streaming with Apache Pulsar
53mEvent Messaging and Streaming with Apache Pulsar
48mApache Pulsar: Event Streaming in The Cloud Native World
45mApache Pulsar: Finally an Alternative to Kafka?
46mApache Pulsar: Finally an Alternative to Kafka?
47mEvent Streaming for the Best of All Worlds
