A Beginner's Guide to Inter-Service Messaging
summary
Fedora Infrastructure moves from 0MQ experiments to an AMQP broker running as a three-node RabbitMQ cluster with mirrored durable queues, uses JSON + JSON Schema to stop silent breakage, and measures surprising throughput like 728 messages/sec on cheap single-board hardware. Early lack of schemas causes consumer crashes and missing user badges; migration strategy is ad hoc so publishers send v1 and v2 topics during transitions. Durable queues reduce lost messages but duplicate delivery and schema evolution remain operational problems.
AI-written summary · about
chapters (32)
- 0:00Intro
- 2:25Why send messages
- 4:41Messaging protocols
- 5:14Reliability
- 6:47Recommendation
- 7:25Questions
- 7:39Maturity
- 9:17Performance
- 10:42Benchmarks
- 12:59Broker Names
- 14:32Kafka
- 17:15Design a Good Message
- 17:45Serialization Formats
- 18:53Message Schema
- 19:39Message Topics
- 22:40Message Migration
- 23:19CrossLanguage Implementation
- 24:10What to Avoid
- 26:31Bus Crashes
- 27:33Rebooting
- 28:06Comments
- 29:29Hotbit
- 32:17Duplicates
- 34:53Exactly Once Model
- 36:24Clustering
- 37:26Distributed architectures
- 37:57Performance metrics
- 38:41Three cluster setup
- 39:27Federal badges
- 41:29Mesh
- 41:59Points of Failure
- 42:24Example
related talks
32mRabbitMQ in Real Life - Tips and Tricks
49mA Love Letter to Messaging: Celebrating RabbitMQ's Journey
30mA love letter to messaging: Celebrating RabbitMQ's journey
48mBuilding a Distributed Data Ingestion System with RabbitMQ
22mLessons Learned from Scaling RabbitMQ in a High-Growth (...)
19mBuilding a Distributed Data Ingestion System with RabbitMQ
39mReal World RabbitMQ: Exploring Practical Applications
24mAdvanced RabbitMQ Strategies: A case study