Adopting Polyglot Flow
summary
Argues that pick brokers by semantics not slogan: use queue for commands (locking, requeue, delay queues, DLQ, competing consumers) and stream for sequential events (offsets, partitioning, archive and replay, consumer groups). Shows RabbitMQ/RMQ patterns for queues and Kafka for streams, cites Kafka Connect and ksql for aggregation/filtering, and notes Pulsar/NATS blur the line by supporting both. Warns polyglot flow raises ops cost so evaluate required features and Kubernetes/cloud availability to choose the smallest set of brokers.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:41The case for polyglot flow
- 4:54Taxonomy of messaging systems
- 9:37Queues versus streams
- 14:42Scaling and reliability
- 17:14Commands, events, and workflows
- 24:25Data dependencies and patterns
- 31:00Stream processing and integration
- 35:20Infrastructure and environmental factors
- 38:22Final summary and recommendations
- 40:07Q&A session
related talks
42mIt's like 10,000 streams when what you need is a queue
47mChoosing the Right Messaging Platform for Your Event-Driven Application
39mReal World RabbitMQ: Exploring Practical Applications
02h 42m!!! Do not publish or share !!!!
24mAdvanced RabbitMQ Strategies: A case study
50mHustle and Flow
27mPatterns for Event-Driven APIs
47mYou Keep Using That Word