How not(!) to build real-time apps
summary
Compares three backend event sources and claims Change Data Capture is the most elegant and robust because it removes the dual-write problem: app-level updates fail to scale across instances, polling becomes CPU/DB intensive per user, and naive pub/sub still faces transactional gaps. Shows a demo stack using Debezium + Kafka + Zookeeper + MySQL as the classic CDC path, then a working demo using Prisma Pulse (runs Debezium for you) with a Prisma Pulse async iterator subscribing to a table; it reliably emits DB-created chat events, costs money and is in private beta.
AI-written summary · about
chapters (10)
- 0:00Introduction to real-time apps
- 1:47Application-level updates approach
- 4:19Problems with application-level updates
- 5:21Polling as an alternative
- 7:52Drawbacks of polling
- 8:36Adding message queue infrastructure
- 9:39Dual write problem persists
- 10:22Change data capture solution
- 12:50Prisma Pulse demo
- 13:32Recap and takeaways
related talks
01h 09mOpen-source Change Data Capture With Debezium
23mChange Data Capture: A RabbitMQ and Debezium Approach
41mChange Data Streaming Patterns in Distributed Systems
27m"Write Once Stream Everywhere: Transforming Your Data into Events"
43mBack to fundamentals: from databases to event-driven platforms
46mSpell of Transmutation - Using Debezium to Transfer Realtime Data Changes to Event Hub
39mModern Event-driven Architecture: Adopting Data in Motion
48mStreaming Database Changes with Debezium