What are Message Queues and Why They Matter for Modern Software Systems

The Black Friday Nightmare

It’s Black Friday morning and your e-commerce application went viral on social media and within minutes 49,999 users are hitting your big “Buy Now” offer button, placing orders, making payments, getting confirmation emails. So, your servers are busy, database connection maxed out and payment processing are timing out, services are crashing one by one, just raw API calls bombarding your servers. To survive, your system scrambles to multitask, spawn threads, or spin up new containers in the cloud. But while it works, the traffic spikes faster than scaling can catch up. So users are feeling frustrated about the slow-ness of your application which will lead to huge loss. Does this sound familiar? This digital nightmare isn’t just poor code or inadequate infrastructure, it’s a fundamental flaw in traditional client-server architecture that crumbles under pressure. But what if there was a simple, elegant pattern that keeps everything flowing smoothly, even when traffic explodes?

Let's discuss a topic I found very interesting - Message Queues, maybe you've heard that before. It's a concept that’s been quietly powering the world’s most resilient systems for decades, and in 2025, it’s still working miracles behind the scenes.

So let’s dive into this concept and grab some pointers.

‍

Table of Contents

1. What Are Message Queues?
2. Core Components Explained
3. How Does Message Routing Work?
4. When Do You Actually Need Message Queues?
5. Choosing the Right Queue Service
6. Key Benefits That Matter
7. A Complete Implementation + Demo + source code
   ‍

1. What Are Message Queues?

A message queue is a simple communication pattern that enables different parts of your application to handle requests and responses asynchronously. Think of it as a reliable middleman that temporarily holds messages sent by producers and delivers them to consumers when they’re ready. This asynchronous communication model prevents data loss and ensures your system remains functional even when individual services fail. It allows developers to build services that are separate, self-contained, and event-driven, creating a decoupled architecture that’s far more reliable than traditional direct API calls.

2. Core Components Explained

‍
1. Producer (Publisher or Sender)

A producer is any service or application that generates a message and pushes it into the queue. It doesn’t care how, when, or who processes the message.

Ex; When you click “Place Order” on Amazon, the order service (producer) creates an “Order Placed” message. This message goes into a queue without worrying whether the payment service, inventory service, or shipping service

‍

2. Message

A message is simply a data packet sent through the queue. It usually contains two things,

• Payload → the actual business data (e.g., order details, user info).
• Metadata → supporting details like timestamps, unique IDs, or routing keys to help the system handle the message properly.

Ex;

{
  "orderId": "ORD123456",
  "userId": "U1024",
  "items": [
    { "productId": "P501", "quantity": 2 },
    { "productId": "P802", "quantity": 1 }
  ],
  "totalAmount": 149.99,
  "currency": "USD",
  "eventType": "ORDER_PLACED",
  "timestamp": "2025-08-24T10:20:00Z"
}

‍

3. Queue

The queue manages message persistence, ordering, and delivery. Worked as a temporary storage place where messages wait before being processed. It acts as a reliable buffer that holds messages in order, and it ensures no data is lost even during a peek or a system failure. Typically works first in a first-in-first-out order.

Ex; During the offer period, hundreds of orders queue up safely. Even if the system goes down for 2 minutes, no orders are lost as they wait in the queue.

‍

4. Consumer (Subscriber)

The service that retrieves and processes messages from the queue. Multiple consumers can often process messages from the same queue for better scalability.

Ex; Once you get an “ORDER_PLACED” message

• The Payment Service pulls the message to charge from the customer’s card.
• The Inventory Service updates stock levels.
• The Notification Service consume the message to send an order confirmation email or SMS.

‍

Other Notes

1. Message Broker

In some systems, this acts as an intelligent person between sender and receiver and provides functionality like message routing, filtering, transformation, and exchange mechanisms that determine how messages are distributed across different queues and consumers.

Ex; The message broker takes your single purchase and intelligently routes it to multiple queues

• Payment Queue → for charging
• Inventory Queue → for stock update
• Notification Queue → for sending confirmation emails

2. Acknowledgement

A confirmation signal that consumers send back to the queue after successfully processing a message to ensure reliability and prevents message loss. If there is no acknowledgement, the queue will retry or redirect the message to another consumer.

‍

The Complete Flow

‍

3. How Message Routing Works

In queues, it is important to have routing mechanisms for certain scenarios because not every message should be sent to everyone. We need to route them to the correct destination. It's similar to a person at the entrance of a bank who asks about your needs and directs you to a specific location; similarly, this message queue has a routing mechanism to do the same, and there are several types of methods.

Direct Routing

Messages go straight to a specific queue by name. Like sending mail to a specific address, simple and direct.

Topic-Based Routing

Publishers send messages to topics like “orders” or “notifications”, and consumers subscribe to topics they care about. One message can reach multiple interested consumers.

Pattern Matching

Uses wildcards to match message types‍

user.* matches user.created, user.updated, user.deleted

orders.# matches anything starting with orders.

Content-Based Routing

The message broker looks inside the message content to decide where it goes. For example, routing customer orders by region or priority level.

And there are more types based on the queue service provider.

4. When Do You Actually Need Message Queues?

As mentioned in the beginning, queues are specialized for specific sets of problems and help make systems asynchronous, decoupled, scalable, and fail-proof. But here’s the thing, knowing what message queues are is one thing, knowing when to actually use them is where the real magic happens. Remember our Black Friday disaster from the opening? Here are the exact scenarios where message queues would have saved the day and turned that nightmare into a smooth, profitable experience. Let’s dive into some real-world use cases where this concept truly shines in action.

1. Microservices Architecture

Problem: Imagine your e-commerce app has 8 microservices → User Service, Order Service, Payment Service, Inventory Service, Shipping Service, Email Service, Analytics Service, and Review Service. Without message queues, when a user places an order, your Order Service has to directly call all these services one by one. If any service is down or slow (different services take different times to respond), your entire order process gets slow. It will be worse if one service crashes.

Solution: With message queues, Order Service simply drops an “ORDER_PLACED” message into a queue and moves on. Each microservice picks up messages they subscribed like this,

• Payment Service: “I’ll handle the charging”
• Inventory Service: “I’ll update the stock”
• Email Service: “I’ll send the confirmation”
• Analytics Service: “I’ll log this for reporting”

Each service works at its own pace, independently. If the Payment Service is down for 2 minutes, the message waits patiently in the queue.

2. Background Processing (Heavy task)

Problem: A user uploads a 10GB video and waits 30 minutes until the server processes it. Meanwhile, your entire application becomes slow because all server resources are tied up with video encoding. Other users can’t load any web pages or request any service from your application, and your platform essentially becomes a one-person-at-a-time system. Every heavy task (video processing, PDF generation, image processing) blocks your main application thread, which makes frustrating experience for users.

Solution: Drop the heavy processing task into a background queue and give users instant feedback like, “Video uploaded! Processing in progress…” Dedicated worker services handle the heavy lifting behind the scenes while your main app stays lightning fast. Users get progress notifications in real time and can continue using your platform normally.

3. Bulk Notifications (Email/SMS Campaigns)

Problem: Your system handles multiple types of emails like password resets, marketing campaigns, account signups, security alerts, and promotional notifications. Without message queues, your main application usually sends all emails synchronously. But when marketing decides to send 50,000 Black Friday emails and notifications, your server gets overwhelmed, blocks application threads, users can’t reset passwords, new signups fail, and your entire platform becomes unresponsive.

Solution: Create an email queue where all email requests land as formatted message objects with recipient, subject, content, and priority. Multiple users can simply drop email messages into the queue and continue working. A dedicated email consumer service consumes messages one by one and sends them. This approach is highly scalable. In a seasonal period, you can spin up multiple email worker instances that all consume from the same queue, processing emails in parallel. Your main app stays fast, prevents failures, and bulk campaigns happen smoothly in the background without affecting user experience.

4. Load Levelling (Peek times)

Problem: A university’s student portal releases exam results at exactly 3 PM. Within seconds, 100,000+ students and parents are continuously hitting refresh, trying to check grades. The server, designed to handle maybe 1,000 concurrent users, normally but suddenly gets 100x the unexpected traffic. The database crashes, servers freeze, and everyone gets stuck; nobody can actually see their results.

Solution: Message queues can act as a traffic controller and temporary parking lot for requests. When those 100,000 result-check requests come in, they land safely in a queue instead of directly hitting the database. Your system processes these requests at a steady, manageable rate instead of 100,000 all at once. Students might have to wait 2–3 minutes to see their results, but everyone will be able to see their results. Additionally, in the meantime, the auto-scaling kicks in and spins up additional server instances to handle the queue backlog quickly. The queue essentially becomes a fail-safe area while giving you time to scale up gracefully.

‍

5. Choosing the Right Queue Service

RabbitMQ

Specialty → General-purpose, reliable, flexible routing.

Why → RabbitMQ is known for its robust features that ensure message delivery, such as message acknowledgements, publisher confirms, and persistent messages. Its support for various protocols like AMQP (its native protocol), MQTT, and STOMP makes it highly versatile for different use cases.

Kafka

Specialty → High-scale, event streaming & data pipelines.

Why → Kafka is not a traditional message queue; it’s a distributed commit log designed for ingesting and processing vast volumes of data in real-time. It’s the go-to solution for event sourcing, log aggregation, and real-time analytics pipelines due to its speed, durability, and fault-tolerance.

AWS SQS

Specialty → AWS-native, serverless & scalable.

Why → SQS is a simple, highly scalable queue-as-a-service offering. Its primary advantage is that it’s fully managed, meaning you don’t have to worry about servers, capacity planning, or scaling. It integrates seamlessly with other AWS services.

Google Cloud Pub/Sub

Specialty → GCP-native, global, real-time.

Why → Pub/Sub is a managed service that focuses on the publish-subscribe model, allowing for asynchronous communication between services. It’s designed for global-scale applications and scales automatically to handle billions of messages, making it great for analytics and event-driven architectures on Google Cloud.

Azure Service Bus

Specialty → Enterprise features & guarantees (dead-letter, duplicate detection, transactions).

Why → Service Bus is a key component of Microsoft’s Azure cloud and is built for enterprise applications that require advanced messaging patterns. Features like dead-lettering (for handling messages that fail to process), duplicate detection, and message sessions make it suitable for complex business processes where strict message delivery and ordering are critical.

Redis Streams

Specialty → Speed-first, lightweight workloads.

Why → Unlike the other systems, which are dedicated messaging brokers, Redis Streams is a data structure within the Redis in-memory data store. This gives it extremely low latency, making it ideal for high-speed, real-time use cases like IoT or microservice communication where the performance of an in-memory database is a huge benefit.

ActiveMQ

Specialty → Legacy enterprise (JMS-heavy environments).

Why → ActiveMQ is a long-standing, open-source message broker. Its main legacy and continued use are tied to the JMS (Java Message Service) API, making it a common choice in Java-based enterprise environments, though it also supports other protocols.

‍

6. Key Benefits That Matter

Decoupling

Message queues act as a buffer between the different components of your system. A “producer” service sends a message to the queue and doesn’t care who receives it or when. A “consumer” service retrieves messages from the queue and processes them, without knowing who sent them. This separation means you can update, replace, or scale a service without affecting the others, making the system more modular and easier to maintain.

Async Communication

This is the core of a message queue’s function. The producer service doesn’t have to wait for an immediate response. It simply adds a message to the queue and moves on. This is especially useful for time-consuming tasks like image processing, sending emails, or generating reports. By offloading these tasks to a queue, the main application remains responsive and fast for the user.

Scalability

Message queues make it easy to scale producers and consumers independently. If a specific task, like order processing, is experiencing a surge in requests, you can add more consumer instances to pull messages from the queue and process them in parallel. On the other hand, if your producers are generating a high volume of data, the queue acts as a buffer, preventing the consumers from being overwhelmed. This allows your system to handle traffic spikes gracefully.

Resilience

With a message queue, messages are stored persistently until they are successfully processed(By using Redis). If a consumer service fails, the messages remain safely in the queue. When the service is brought back online, it can continue processing messages from where it left off, ensuring no data is lost. This fault-tolerance is crucial for mission-critical applications where data integrity is important.

Load Balancing

Instead of a single service being bottlenecked by a high volume of tasks, the queue spreads the messages across all available consumers. This ensures that no single consumer is overwhelmed, and resources are utilized efficiently and helping to better overall system performance and throughout.

‍

7. Build Your Own → A Complete Implementation

Let’s dive into the interesting part. Until now, we’ve discussed how things work theoretically, but those won’t work in the real world. So we should have implementation experience. Let’s get our hands dirty!

This might not be a fully beginner-friendly implementation. This is a simple but slightly improved version that came into my mind with the problem we discussed at the beginning of the blog, and I wanted to do some experiments as well.

E-Commerce Order Processing Scenario

When a user places an order, here’s what happens behind the scenes:

System Architecture

Message Exchange:

order-process-exchange

Routing Keys:

order.inventory - Route to inventory processing
order.payment - Route to payment processing
order.complete - Route to completion services (email, SMS, order update)
order.status - Route to logging service

Queues & Bindings:

inventory.queue ← order.inventory
payment.queue ← order.payment
email.queue ← order.complete
sms.queue ← order.complete
order.complete.queue ← order.complete
logger.queue ← order.status

Services Overview

1. Order Service

Role: Publisher + Consumer

• ‍Publishes to: inventory.queue (starts the processs
• ‍Consumes from: order.complete.queue (final confirmation)‍
• Does: Receives API calls, initiates order processing, and shows final success

2. Inventory Service

Role: Consumer + Publisher

• Consumes from: inventory.queue
• Publishes to: payment.queue, logger.queue
• Does: Checks stock availability, updates inventory, passes to payment

3. Payment Service

Role: Consumer + Publisher

• Consumes from: payment.queue
• Publishes to: order.complete.queue, logger.queue
• Does: Processes payment, triggers completion flow

4. Email Service

Role: Consumer + Publisher

• Consumes from: email.queue
• Publishes to: logger.queue
• Does: Sends order confirmation email

5. SMS Service

Role: Consumer + Publisher

• Consumes from: sms.queue
• Publishes to: logger.queue
• Does: Sends order confirmation SMS

6. Logger Service

Role: Consumer Only

• Consumes from: logger.queue
• Does: Logs all system activities and status updates

Prerequisites & Setup

1. Install RabbitMQ with Docker

# Pull RabbitMQ image with management UI
docker pull rabbitmq:3-management

# Run RabbitMQ container
docker run -d --name rabbitmq \\
  -p 5672:5672 \\
  -p 15672:15672 \\
  rabbitmq:3-management
# Access Management UI: <http://localhost:15672>
# Username: guest, Password: guest

2. Required NPM Packages

# For Order service
npm init -y
npm install amqplib express body-parser
npm install -g nodemon

# for other services
npm init -y
npm install amqplib
npm install -g nodemon

Package explanations:

• amqplib - RabbitMQ client for Node.js
• express - API server for order endpoints
• body-parser - parse request bodies
• dotenv - Environment variable management
• nodemon - Auto-restart during development

Implementation Files

This project contains 6 services, let’s discuss them one by one.

Order-service

// project Structure
├─ order-service/
   ├── package.json
   ├── index.js
   ├── orderService.js
   ├── producer.js
   └── consumer.js

index.js

import express from 'express';
import bodyParser from 'body-parser';
import { OrderService } from './orderService.js';
import { Producer } from './producer.js';
import { Consumer } from './consumer.js';

// Create Express app instance
const app = express();

// Middleware to parse JSON requests
app.use(bodyParser.json('application/json'));

// Wrap the initialization in an async function
async function startServer() {
 try {
  // Initialize order service and get message queue channel
  const orderService = OrderService.getInstance();
  await orderService.init();
  const channel = orderService.getChannel();

  // Set up message queue consumer and producer
  const consumer = new Consumer(channel, orderService.getQueueName());
  const producer = new Producer(channel, consumer);

  // Route to handle order placement
  app.post('/place-order', async (req, res, next) => {
   const orderData = req.body;

   try {
    // Publish message to update inventory
    await producer.publishUpdateInventoryMessage('order.inventory', orderData);
    res.status(200).send('Order is being processed');
   } catch (error) {
    console.log(error);
    res.status(500).send('Error processing order');
   }
  });

  // Start the server
  app.listen(3000, () => {
   console.log('✅ Server is listening on port 3000');
  });
 } catch (error) {
  console.error('💥 Failed to start Order Service:', error);
  process.exit(1);
 }
}

// Start the application
startServer();

orderService.js

import amqp from 'amqplib';

export class OrderService {
 static instance;
 static connection;
 static channel;
 static queueName;

 // Singleton constructor - ensures only one instance exists
 constructor() {
  if (OrderService.instance) {
   return OrderService.instance;
  }
  OrderService.instance = this;
 }

 // Get the singleton instance
 static getInstance() {
  if (!OrderService.instance) {
   OrderService.instance = new OrderService();
  }
  return OrderService.instance;
 }

 // Initialize RabbitMQ connection and channel
 async init() {
  // Connect to RabbitMQ server
  if (!OrderService.connection) {
   OrderService.connection = await amqp.connect('amqp://localhost');
   console.log('✅ Connected to RabbitMQ');
  }
  // Create a channel for communication
  if (!OrderService.channel) {
   OrderService.channel = await OrderService.connection.createChannel();
   console.log('✅ Channel created');
  }

  await this.setupExchangeAndQueues();
 }

 // Configure exchange and queue bindings
 async setupExchangeAndQueues() {
  // Create direct exchange for order processing
  await OrderService.channel.assertExchange('order-process-exchange', 'direct');
  // Create queue for completed orders
  const q = await OrderService.channel.assertQueue('order.complete.queue');
  // Bind queue to exchange with routing key
  await OrderService.channel.bindQueue(q.queue, 'order-process-exchange', 'order.complete');
  OrderService.queueName = q.queue;
  console.log('✅ Exchange and queues configured');
 }

 // Get the RabbitMQ connection
 getConnection() {
  return OrderService.connection;
 }

 // Get the RabbitMQ channel
 getChannel() {
  return OrderService.channel;
 }

 // Get the queue name
 getQueueName() {
  return OrderService.queueName;
 }
}

producer.js

export class Producer {
 constructor(channel, consumer) {
  this.channel = channel;
  this.consumer = consumer;
 }

 // Publishes an inventory update message and triggers order completion consumption
 async publishUpdateInventoryMessage(routingKey, orderData) {
  // await this.channel.assertExchange('order-process-exchange', 'direct');

  // Create inventory message with order status and timestamp
  const inventoryMessage = {
   ...orderData,
   orderStatus: 'PLACED',
   timestamp: new Date().toISOString(),
  };

  // Publish inventory message to exchange
  await this.channel.publish('order-process-exchange', routingKey, Buffer.from(JSON.stringify(inventoryMessage)));
  console.log(`Message published to exchange order-process-exchange with routing key ${routingKey}`);

  // Publish status update for order placement
  await this.publishStatusMessage(orderData.orderId, 'order.status', 'ORDER_PLACED');

  // Start consuming order completion messages
  this.consumer.consumeMessage('order.complete.queue');
 }

 // Publishes a status message for order tracking
 async publishStatusMessage(orderId, routingKey, status) {
  // await this.channel.assertExchange('order-process-exchange', 'direct');

  // Create status message with service identifier
  const statusMessage = {
   orderId,
   service: 'ORDER',
   status,
   timestamp: new Date().toISOString(),
  };

  // Publish status message to exchange
  await this.channel.publish('order-process-exchange', routingKey, Buffer.from(JSON.stringify(statusMessage)));
  console.log('Status update published:', status, 'for', orderId);
 }
}

consumer.js

export class Consumer {
 constructor(channel) {
  // Store the message queue channel for consuming messages
  this.channel = channel;
 }

 async consumeMessage(queueName) {
  // Set up message consumption from the specified queue
  this.channel.consume(queueName, (msg) => {
   if (msg) {
    // Parse the message content from buffer to JSON
    const data = JSON.parse(msg.content.toString());
    console.log('📨 Received message:', data);

    // Acknowledge the message as processed
    this.channel.ack(msg);
   }
  });
 }
}

‍

Inventory Service

// Folder structure
├─ inventory-service/
   ├── package.json
   ├── index.js
   ├── inventoryService.js
   ├── producer.js
   └── consumer.js

index.js

import { Consumer } from './consumer.js';
import { InventoryService } from './inventoryService.js';
import { Producer } from './producer.js';

async function main() {
 try {
  // Initialize the inventory service singleton
  const inventoryService = InventoryService.getInstance();
  await inventoryService.init();

  // Get the message queue channel
  const channel = inventoryService.getChannel();

  // Create producer and consumer instances
  const producer = new Producer(channel);
  const consumer = new Consumer(channel, inventoryService.getQueueName(), producer);

  // Start consuming messages from the queue
  await consumer.consumeMessage();

  console.log('🏪 Inventory Service running...');
 } catch (error) {
  // Handle any startup errors
  console.error('💥 Failed to start Inventory Service:', error);
  process.exit(1);
 }
}

// Start the application
main();

orderService.js

import amqp from 'amqplib';

export class InventoryService {
 static instance;
 static connection;
 static channel;
 static queueName;

 constructor() {
  // Ensure only one instance exists (singleton pattern)
  if (InventoryService.instance) {
   return InventoryService.instance;
  }
  InventoryService.instance = this;
 }

 static getInstance() {
  // Get or create the singleton instance
  if (!InventoryService.instance) {
   InventoryService.instance = new InventoryService();
  }
  return InventoryService.instance;
 }

 async init() {
  // Connect to RabbitMQ if not already connected
  if (!InventoryService.connection) {
   InventoryService.connection = await amqp.connect('amqp://localhost');
   console.log('✅ Connected to RabbitMQ');
  }
  // Create channel if not already created
  if (!InventoryService.channel) {
   InventoryService.channel = await InventoryService.connection.createChannel();
   console.log('✅ Channel created');
  }

  await this.setupExchangeAndQueues();
 }

 async setupExchangeAndQueues() {
  // Create exchange for order processing
  await InventoryService.channel.assertExchange('order-process-exchange', 'direct');
  // Create inventory queue
  const q = await InventoryService.channel.assertQueue('inventory.queue');
  // Bind queue to exchange with routing key
  await InventoryService.channel.bindQueue(q.queue, 'order-process-exchange', 'order.inventory');
  InventoryService.queueName = q.queue;
  console.log('✅ Exchange and queues configured');
 }

 // Getter methods for accessing connection, channel, and queue name
 getConnection() {
  return InventoryService.connection;
 }

 getChannel() {
  return InventoryService.channel;
 }

 getQueueName() {
  return InventoryService.queueName;
 }
}

Producer.js

export class Producer {
 constructor(channel) {
  this.channel = channel;
 }

 // Publishes inventory confirmation message and status update
 async publishInventoryMessage(routingKey, orderData) {
  // await this.channel.assertExchange('order-process-exchange', 'direct');

  // Create inventory message with confirmed status
  const inventoryMessage = {
   ...orderData,
   inventoryStatus: 'CONFIRMED',
   timestamp: new Date().toISOString(),
  };

  // Publish inventory message to exchange
  await this.channel.publish('order-process-exchange', routingKey, Buffer.from(JSON.stringify(inventoryMessage)));
  console.log(`Message published to exchange order-process-exchange with routing key ${routingKey}`);

  // Send status update message
  await this.publishStatusMessage(orderData.orderId, 'order.status', 'INVENTORY_CONFIRMED');
 }

 // Publishes status update messages
 async publishStatusMessage(orderId, routingKey, status) {
  // await this.channel.assertExchange('order-process-exchange', 'direct');

  // Create status message
  const statusMessage = {
   orderId,
   service: 'INVENTORY',
   status,
   timestamp: new Date().toISOString(),
  };

  // Publish status message to exchange
  await this.channel.publish('order-process-exchange', routingKey, Buffer.from(JSON.stringify(statusMessage)));
  console.log('Status update published:', status, 'for', orderId);
 }
}

consumer.js

export class Consumer {
 constructor(channel, queueName, producer) {
  // Store the message queue channel
  this.channel = channel;
  // Store the queue name to consume from
  this.queueName = queueName;
  // Store the producer for publishing messages
  this.producer = producer;
 }

 async consumeMessage() {
  // Start consuming messages from the queue
  this.channel.consume(this.queueName, (msg) => {
   if (msg) {
    // Parse the message content from JSON
    const data = JSON.parse(msg.content.toString());
    console.log('📨 Received message:', data);

    // Forward the message to the payment queue
    this.producer.publishInventoryMessage('order.payment', data);

    // Acknowledge the message as processed
    this.channel.ack(msg);
   }
  });
 }
}

Since other services also looks almost similar I will not be including them here. Please Check at the end of the blog for the GitHub repo link to complete this project. Feel free to use some AI tools to understand this even better.

How to Run the System

1. Start RabbitMQ

docker run -d --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3-management

2. Start All Services (in separate terminals)

# Terminal 1: Order Service (includes API)
nodemon index
# Terminal 2: Inventory Service
nodemon index
# Terminal 3: Payment Service
nodemon index
# Terminal 4: Email Service
nodemon index
# Terminal 5: SMS Service
nodemon index
# Terminal 6: Logger Service
nodemon index

3. Test the System

# Place an order
curl --location '<http://localhost:3000/place-order>' \\
--header 'Content-Type: application/json' \\
--data '{
    "orderId": "35454",
    "name": "Mechanical Mouse",
    "price": 100,
    "userId" : "user-001"
}

What You’ll See

When you run the system and place an order, you’ll see a beautiful cascade of messages across all terminal windows.

1. Order Service: Creates order and publishes to inventory
2. Inventory Service: Processes stock, publishes to payment & logger
3. Payment Service: Processes payment, publishes to completion & logger
4. Email Service: Sends email, publishes to logger
5. SMS Service: Sends SMS, publishes to logger
6. Logger Service: Records all activities
7. Order Service: Receives completion confirmation

RabbitMQ Management Interface

Access http://localhost:15672 for;

• Exchanges: Your order-process-exchange
• Queues: All 6 queues with message counts
• Connections: All service connections
• Message Flow: Real-time message routing

Demo Video

I have created a small video about the working demo of this project, which shows how to start, run and project results.

Key Learning Points

This implementation shows

• Decoupled Architecture: Services don’t know about each other
• Fault Tolerance: If one service fails, messages wait in queues
• Scalability: Easy to add more consumers to any queue
• Reliability: Message acknowledgement ensures no data loss
• Flexibility: Easy to add new services or change routing

Next Steps

Try these experiments

1. Stop a service mid-process and see messages waiting in queues
2. Start multiple instances of the same service for load balancing
3. Add new services like inventory-alert or order-analytics
4. Implement error handling with dead letter queues
5. Add message persistence for even better reliability

Complete Code Repository

This implementation shows the real power of message queues in action. You’ve just built a distributed, fault-tolerant, scalable system that can handle thousands of orders without breaking a sweat! 🚀