Event-Driven Message Broker
Visual simulation of asynchronous message flow through an exchange-based broker. Demonstrates producer-consumer decoupling, queue backpressure, and fan-out routing — the patterns behind the RabbitMQ and Redis architectures built at GoTech.
Initialization • Click 'Initialize Simulation' to start the message broker visualization Operation • Adjust the 'Publish Rate' slider to control how fast producers emit messages • Click 'Add Consumer' to attach more consumers to process the queue • Click 'Remove Consumer' to simulate consumer failure • Toggle 'Fan-Out Mode' to broadcast messages to all queues simultaneously Observation • Messages (particles) flow from producers through the exchange to queues • Queue depth grows when consumers can't keep up (backpressure) • The metrics panel shows throughput, queue depth, and consumer utilization
Need Cloud Infrastructure & Platform Engineering?
From prototypes to production-grade systems.
The Problem: Tight Coupling
Synchronous request-response architectures create tightly coupled systems. In the PHP monolith project GoTech worked with, every operation was processed inline — a slow email notification would delay the entire checkout flow. When we migrated to microservices, asynchronous messaging became the connective tissue between services.
Exchange-Based Routing
This simulation models the AMQP (Advanced Message Queuing Protocol) exchange patterns used in RabbitMQ:
- Direct Exchange: Messages routed to a specific queue based on a routing key. One-to-one communication.
- Fan-Out Exchange: Messages broadcast to all bound queues simultaneously. One-to-many notification patterns (e.g., “order placed” triggers inventory, billing, and email services in parallel).
Backpressure and Flow Control
When consumers process messages slower than producers emit them, queues grow — this is backpressure. In production systems, this manifests as:
- Memory pressure on the broker node.
- Increased latency for downstream operations.
- Potential message loss if queues hit configured limits.
The simulation visualizes this in real time. Adding consumers relieves pressure; removing them causes accumulation.
Real-World Application
- GoTech: Migrated from synchronous PHP monolith to Node.js microservices connected via RabbitMQ exchanges and Redis pub/sub. Decoupled user-facing requests from asynchronous processing (email, PDF generation, analytics).
- Rapid7: Cyber threat intelligence ingestion pipeline processed millions of indicators asynchronously — message queues buffered bursts from upstream threat feeds.
- Kiwibank: Event-driven patterns for transaction processing — banking events published to downstream services for audit, notification, and compliance.
References
[1] Kleppmann, M. (2017). Designing Data-Intensive Applications. O’Reilly Media.
[2] Videla, A. & Williams, J.J.W. (2012). RabbitMQ in Action. Manning Publications.
[3] RabbitMQ Documentation. (n.d.). “AMQP Concepts.” Retrieved from https://www.rabbitmq.com/tutorials/amqp-concepts.html