Message Queues Demystified - Part 1: Fundamentals

"The single biggest problem in communication is the illusion that it has taken place."
This applies directly to distributed systems. Message queues solve that illusion with guarantees.

Table of Contents

1. The Problem - Why We Need Message Queues
2. What is a Message Queue
3. Real-World Analogies
4. Core Components and Vocabulary
5. Anatomy of a Message
6. Synchronous vs Asynchronous Communication
7. Queue vs Topic - A Critical Distinction
8. Communication Models
9. Key Benefits
10. When to Use and When to Avoid

1. The Problem - Why We Need Message Queues

The Tight Coupling Problem

Imagine you are building an e-commerce application. When a customer places an order, your system needs to:

1. Charge the customer's credit card
2. Update inventory in the database
3. Send an order confirmation email
4. Notify the warehouse to pick and ship items
5. Update analytics and reporting dashboards
6. Generate and store an invoice
7. Award loyalty points to the customer

The naive approach is to wire everything together with direct synchronous calls from your Order Service:

// The naive approach - direct synchronous calls
public OrderResponse placeOrder(OrderRequest request) {
 
    // Step 1 - charge the card (blocks and waits ~150ms)
    paymentService.charge(request.getPaymentDetails());
 
    // Step 2 - update inventory (blocks and waits ~80ms)
    inventoryService.reserve(request.getItems());
 
    // Step 3 - send confirmation email (blocks and waits ~300ms)
    emailService.sendConfirmation(request.getEmail());
 
    // Step 4 - notify warehouse (blocks and waits ~200ms)
    warehouseService.createShipment(request);
 
    // Step 5 - track analytics (blocks and waits ~50ms)
    analyticsService.track("ORDER_PLACED", request);
 
    // Step 6 - generate invoice (blocks and waits ~100ms)
    invoiceService.generate(request);
 
    // Step 7 - award loyalty points (blocks and waits ~60ms)
    loyaltyService.awardPoints(request.getCustomerId(), request.getTotalAmount());
 
    // Total wait time: 940ms minimum - and that is on a good day
    return new OrderResponse("SUCCESS");
}

This works locally. In production, it falls apart in spectacular ways.

Problem 1: Latency Multiplication

Each call adds its processing time to the total user wait time:

Payment Service:    150ms
Inventory Service:   80ms
Email Service:      300ms  <-- email is NOT urgent to the user
Warehouse Service:  200ms  <-- warehousing is NOT urgent to the user
Analytics Service:   50ms  <-- analytics is definitely NOT urgent
Invoice Service:    100ms
Loyalty Service:     60ms
                   ------
Total minimum:      940ms

The customer waits nearly a full second just to see "Order Confirmed." Most of that time is spent on actions the customer does not care about at that moment. The email being sent has nothing to do with whether the payment went through.

Problem 2: Cascading Failures

If the Email Service is experiencing issues:

Order Service -> Payment Service  (success)
Order Service -> Inventory Service  (success)
Order Service -> Email Service      *** TIMEOUT after 30 seconds ***
                                    *** Order fails entirely ***

The customer cannot place an order because the email system is slow. The payment was charged but the order failed. This is an operational nightmare.

The Email Service being down should have absolutely no effect on whether an order can be placed.

Problem 3: Tight Coupling

The Order Service has intimate knowledge of seven other services:

• It knows their network locations (URLs, hostnames)
• It knows their API contracts (method signatures, request/response formats)
• It depends on their availability to function

Consequences:

• If Email Service changes its API, Order Service must be updated and redeployed simultaneously
• Adding an eighth service (like SMS notifications) requires modifying Order Service code
• Testing Order Service in isolation is impossible - you need all seven services running
• The team that owns Order Service must coordinate every change with seven other teams

Problem 4: No Independent Scaling

During a Black Friday sale, you need to send 100x more emails. But:

• You cannot scale Email Service independently if it is embedded in the Order Service call chain
• Scaling Order Service means scaling all seven downstream services together
• All services must be sized for peak load even if only one needs it during any given peak

Problem 5: Brittle Reliability

• No automatic retry if a service is temporarily unreachable
• A transient network blip causes permanent order failures
• When a service recovers from downtime, there is no backlog to process
• The system has no memory of what it was trying to do when it failed

The Solution: Message Queues

With a message queue, Order Service does only what is immediately necessary:

// The message queue approach
public OrderResponse placeOrder(OrderRequest request) {
 
    // Do the critical synchronous steps only
    Order order = orderRepository.save(request);
 
    // Charge payment - this truly needs to be synchronous
    PaymentResult result = paymentService.charge(request.getPaymentDetails());
    if (!result.isSuccessful()) {
        return new OrderResponse("PAYMENT_FAILED");
    }
 
    // Publish ONE event - fire and forget (takes ~5ms)
    messageQueue.publish("order.placed", OrderPlacedEvent.from(order));
 
    // Return immediately - do NOT wait for email, warehouse, analytics, etc.
    return new OrderResponse("SUCCESS", order.getId());
}

Each downstream service independently listens for events and processes them in its own time:

// Email Service - independent, isolated consumer
@MessageListener(topic = "order.placed")
public void handleOrderPlaced(OrderPlacedEvent event) {
    emailService.sendConfirmation(event.getCustomerEmail(), event.getOrderDetails());
}
 
// Warehouse Service - independent, isolated consumer
@MessageListener(topic = "order.placed")
public void handleOrderPlaced(OrderPlacedEvent event) {
    warehouseService.createPickList(event.getOrderDetails());
}
 
// Analytics Service - independent, isolated consumer
@MessageListener(topic = "order.placed")
public void handleOrderPlaced(OrderPlacedEvent event) {
    analyticsService.recordEvent("ORDER_PLACED", event);
}

Now:

• Order confirmation returns in ~50ms (payment + save only), not 940ms
• If Email Service is down, emails queue up and are sent when it recovers
• Adding SMS Service requires zero changes to Order Service
• Each service scales independently based on its own needs
• Transient failures are retried automatically

2. What is a Message Queue

The Core Definition

A message queue is a form of asynchronous, durable inter-service communication. It acts as an intermediary buffer between a sender (producer) and a receiver (consumer), allowing them to communicate without being directly connected, without knowing about each other, and without needing to be available at the same time.

The Three Core Guarantees

Every message queue, regardless of implementation, provides three guarantees:

1. Storage - Messages are stored durably until consumed or expired
2. Delivery - Messages will be delivered to at least one consumer
3. Decoupling - Producer and consumer do not need direct knowledge of each other

How It Works - Step by Step

Step 1:  Producer creates a message and sends it to the broker
         Producer does NOT wait for it to be processed

Step 2:  Message Broker receives and stores the message durably
         Broker persists it to disk (if configured as durable)

Step 3:  Consumer polls or is notified about the new message
         Consumer reads the message from the queue/topic

Step 4:  Consumer processes the message
         This might take milliseconds or minutes

Step 5:  Consumer sends an acknowledgment (ACK) to the broker
         This tells the broker "I have successfully processed this"

Step 6:  Broker deletes the message (or marks it consumed)
         Message is gone from the queue

** If step 4 or 5 fails (consumer crashes, processing error):
   Broker re-delivers the message after a timeout
   Another consumer instance can pick it up

3. Real-World Analogies

Analogy 1: The Post Office

This is the most intuitive analogy for understanding message queues:

The key insight: You write a letter, drop it in a mailbox, and immediately go on with your day. You do NOT stand at the mailbox waiting for the recipient to appear and read the letter right there. The post office handles the delivery asynchronously. The recipient checks their mail when it is convenient.

What happens when the recipient is on a two-week vacation?

• Letters accumulate in the mailbox (queue depth grows)
• When they return, they process all mail in order (consumer catches up)
• No letters are lost (message durability)
• You (sender) were never blocked or aware of the accumulation

What happens if one letter is badly damaged and cannot be delivered?

• Post office puts it in the "undeliverable mail" pile (Dead Letter Queue)
• A human reviews and manually handles it (DLQ monitoring and processing)
• Normal mail continues to flow (one bad message does not block others)

Analogy 2: The Restaurant Kitchen

The workflow:

1. Waiter takes order, writes ticket, clips it to the rail - then immediately goes to take more orders
2. Chef grabs next ticket from the rail, prepares the dish
3. Chef removes the ticket (acknowledges the message) when dish is ready
4. If a chef gets sick mid-dish, the ticket goes back on the rail for another chef

The waiter is never blocked waiting for the kitchen. The kitchen is never overwhelmed by the waiter. Each operates at its own pace.

If the kitchen falls behind during a dinner rush:

• Tickets pile up on the rail (queue depth increases)
• Management calls in more chefs (scale up consumers)
• The waiter keeps working without slowing down (producer throughput unaffected)

Analogy 3: The Airport Boarding Queue

When an airline boards a flight:

• Gate Agent (Producer): Calls boarding groups and directs passengers to the queue
• Boarding Queue (Queue): The line of passengers waiting to board
• Airplane Door (Consumer): Checks tickets and processes passengers one at a time
• Multiple Doors (Multiple Consumers): Process passengers in parallel, increasing throughput
• Gate Agent's boarding announcements: Messages (events)

The gate agent can fill the queue much faster than the door can process passengers. The queue absorbs the difference. This is load leveling - one of the most valuable properties of message queues.

4. Core Components and Vocabulary

4.1 Producer (Publisher / Sender)

A producer is any application or service that creates and sends messages.

Core characteristics:

• Sends messages and immediately moves on (does not wait for processing)
• Can be one producer or many producers writing to the same destination
• Publishes either events ("something happened") or commands ("please do this")
• Should generally not care how many consumers are listening

Types of things producers publish:

• Domain events: OrderPlaced, PaymentReceived, UserRegistered
• Commands: SendEmail, ResizeImage, GenerateReport
• Facts: sensor readings, log entries, metrics data

Java/Spring Boot example:

@Service
@RequiredArgsConstructor
public class OrderService {
 
    private final OrderRepository orderRepository;
    private final PaymentGateway paymentGateway;
    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;
 
    @Transactional
    public PlaceOrderResponse placeOrder(PlaceOrderRequest request) {
 
        // 1. Save the order
        Order order = Order.create(request);
        orderRepository.save(order);
 
        // 2. Charge payment (synchronous - user needs immediate feedback)
        PaymentResult payment = paymentGateway.charge(
            request.getPaymentToken(),
            request.getTotalAmount()
        );
 
        if (!payment.isSuccessful()) {
            throw new PaymentFailedException(payment.getErrorMessage());
        }
 
        // 3. Publish the event - everything else is async
        OrderPlacedEvent event = OrderPlacedEvent.builder()
            .orderId(order.getId())
            .customerId(order.getCustomerId())
            .totalAmount(order.getTotalAmount())
            .items(order.getItems())
            .shippingAddress(order.getShippingAddress())
            .occurredAt(Instant.now())
            .build();
 
        // Key = orderId ensures all events for same order go to same partition
        kafkaTemplate.send("order-events", order.getId().toString(), event);
 
        return PlaceOrderResponse.success(order.getId());
    }
}

4.2 Consumer (Subscriber / Receiver / Listener)

A consumer is any application that reads and processes messages.

Core characteristics:

• Processes messages at its own pace (independent of producer)
• Must send an acknowledgment when processing completes successfully
• Can be scaled horizontally by adding more instances
• Should be idempotent: processing the same message twice produces the same result as processing it once

Pull vs Push consumers:

• Push model (RabbitMQ, AWS SQS): Broker pushes messages to registered consumer
• Pull model (Kafka): Consumer polls the broker asking "give me the next messages"

Java/Spring Boot example:

@Service
@RequiredArgsConstructor
@Slf4j
public class EmailNotificationConsumer {
 
    private final EmailService emailService;
    private final ProcessedEventRepository processedEventRepository;
 
    @KafkaListener(
        topics = "order-events",
        groupId = "email-notification-group",
        containerFactory = "kafkaListenerContainerFactory"
    )
    public void handleOrderPlaced(
            @Payload OrderPlacedEvent event,
            @Header(KafkaHeaders.OFFSET) long offset,
            Acknowledgment acknowledgment) {
 
        log.info("Processing OrderPlaced event: orderId={}, offset={}",
            event.getOrderId(), offset);
 
        // Idempotency check - have we already processed this?
        if (processedEventRepository.existsByEventId(event.getEventId())) {
            log.warn("Duplicate event detected, skipping: {}", event.getEventId());
            acknowledgment.acknowledge(); // Still ACK so we do not keep receiving it
            return;
        }
 
        try {
            emailService.sendOrderConfirmation(
                event.getCustomerId(),
                event.getOrderId(),
                event.getTotalAmount()
            );
 
            // Record that we have processed this event
            processedEventRepository.save(new ProcessedEvent(event.getEventId()));
 
            // Acknowledge only after successful processing
            acknowledgment.acknowledge();
 
        } catch (Exception e) {
            log.error("Failed to send email for order: {}", event.getOrderId(), e);
            // Do NOT acknowledge - message will be redelivered
            throw e;
        }
    }
}

4.3 Message Broker

The message broker is the central infrastructure that sits between producers and consumers.

Responsibilities:

• Receive messages from producers over a network connection
• Store messages durably (optionally - some brokers are in-memory only)
• Route messages to the correct queues or topics
• Manage delivery guarantees and acknowledgment tracking
• Handle consumer subscriptions and load balancing
• Provide management interfaces, APIs, and monitoring

Popular message brokers and their identity:

4.4 Queue

A queue is an ordered collection of messages waiting to be processed.

Key properties:

• FIFO (First In, First Out): Messages are generally delivered in arrival order
• Exclusive consumption: Once consumed by one consumer, the message is removed
• Durability: Can be configured to survive broker restarts
• Bounded capacity: Can have a maximum depth (messages rejected or oldest dropped when full)
• Point-to-Point: Designed for work distribution - one consumer per message

Competing consumers on a queue:

[Queue: image-resize-jobs]

Job 1 (resize photo-A) --> Worker Instance 1 (processes it, job deleted from queue)
Job 2 (resize photo-B) --> Worker Instance 2 (processes it, job deleted from queue)
Job 3 (resize photo-C) --> Worker Instance 3 (processes it, job deleted from queue)
Job 4 (resize photo-D) --> Worker Instance 1 (comes back for more)

Multiple workers share the queue. Each job goes to exactly one worker. This distributes load automatically.

4.5 Topic

A topic is a named channel where producers publish events that are delivered to ALL subscribers.

Key properties:

• Fan-out: Every message goes to every subscriber group
• Independent consumption: Each consumer group tracks its own position separately
• Retention: Messages may be stored for a period even after consumption (Kafka keeps them; SNS deletes after delivery)
• Pub/Sub: Designed for broadcasting - one message, many independent consumers

How a topic serves multiple consumer groups:

[Topic: order-placed]

OrderPlaced event -->  Email Consumer Group      (each gets their own copy)
                   -->  Analytics Consumer Group  (each gets their own copy)
                   -->  Warehouse Consumer Group  (each gets their own copy)
                   -->  Invoice Consumer Group    (each gets their own copy)

Adding a new SMS Consumer Group requires ZERO changes to the producer.
The producer publishes once. All groups independently receive and process.

4.6 Exchange (RabbitMQ Specific)

In RabbitMQ, producers never publish directly to a queue. They publish to an Exchange, which is a routing agent that decides which queues receive which messages.

Exchange types:

Topic Exchange pattern example:

Routing key: "order.electronics.placed"

Bindings:
  "order.*.placed"      --> Queue: order-confirmation-service  (matches: one word between dots)
  "order.electronics.#" --> Queue: electronics-inventory       (matches: starts with order.electronics)
  "order.#"             --> Queue: audit-log-service           (matches: any order event)
  "#.placed"            --> Queue: analytics-placed-events     (matches: anything ending in .placed)

4.7 Partition (Kafka Specific)

A partition is the fundamental unit of parallelism in Kafka.

• Every Kafka topic is split into one or more partitions
• Each partition is an ordered, immutable log of messages
• Messages within one partition are strictly ordered
• Messages across partitions have NO ordering guarantee
• Each partition can be handled by only ONE consumer within a consumer group
• More partitions = more parallelism = higher throughput

Topic: order-events (3 partitions)

Partition 0:  order-101, order-104, order-107  --> Consumer Instance A
Partition 1:  order-102, order-105, order-108  --> Consumer Instance B
Partition 2:  order-103, order-106, order-109  --> Consumer Instance C

Orders with the same customerId can be routed to the same partition (by using customerId as the partition key), ensuring all events for one customer are processed in order.

5. Anatomy of a Message

A message is the fundamental data unit. A well-structured message enables routing, deduplication, debugging, and schema evolution.

{
  "messageId": "550e8400-e29b-41d4-a716-446655440000",
  "schemaVersion": "2.1",
  "eventType": "OrderPlaced",
  "aggregateType": "Order",
  "aggregateId": "ORD-2026-00123456",
  "timestamp": "2026-06-05T10:30:00.000Z",
  "headers": {
    "contentType": "application/json",
    "sourceService": "order-service",
    "sourceEnvironment": "production",
    "correlationId": "checkout-session-abc123",
    "causationId": "checkout-button-click-event-id",
    "tracingId": "trace-dd9f3a1b2c4e"
  },
  "payload": {
    "orderId": "ORD-2026-00123456",
    "customerId": "CUST-78901",
    "orderDate": "2026-06-05T10:29:58.000Z",
    "status": "PLACED",
    "items": [
      {
        "productId": "PROD-001",
        "productName": "Wireless Keyboard",
        "quantity": 1,
        "unitPrice": 89.99,
        "subtotal": 89.99
      },
      {
        "productId": "PROD-002",
        "productName": "USB Mouse",
        "quantity": 2,
        "unitPrice": 29.99,
        "subtotal": 59.98
      }
    ],
    "shippingAddress": {
      "street": "123 Main Street",
      "city": "San Francisco",
      "state": "CA",
      "zipCode": "94105"
    },
    "totalAmount": 149.97,
    "currency": "USD",
    "paymentMethod": "CREDIT_CARD"
  }
}

Why Each Field Matters

6. Synchronous vs Asynchronous Communication

Synchronous Communication

Client --[request]--> Service A --[request]--> Service B
Client <--[response]-- Service A <--[response]-- Service B

Client is BLOCKED until the entire chain completes.

Asynchronous Communication

Client --[message]--> [Queue] --> Service B
Client <--[ACK]------

Client gets acknowledgment that the message was RECEIVED, not PROCESSED.
Client is NOT blocked waiting for Service B to finish.

The Full Comparison

The Decision Rule

Use synchronous communication when: The producer needs the result of the consumer's processing to complete the current user operation.

Use asynchronous messaging when: The producer just needs to record that something happened and let other systems react in their own time.

Examples:

• "Is this username available?" -> Synchronous (user needs answer NOW)
• "Send a welcome email" -> Asynchronous (user does not need to wait for email to be sent)
• "Process payment and tell me if it succeeded" -> Synchronous (user needs to know)
• "Update analytics dashboard" -> Asynchronous (user does not care about analytics)

7. Queue vs Topic - A Critical Distinction

This is arguably the most important conceptual distinction in messaging systems.

Queue (Point-to-Point Model)

A queue is used for work distribution. When you want to share a workload across multiple workers.

Rules:

• A message is consumed by exactly one consumer
• Message is removed from the queue after successful consumption
• Multiple consumers on the same queue = competing consumers sharing the load
• No replay - once consumed, it is gone

Visual:

[Queue: image-processing-jobs]

Img-1 ------------> Worker A  (processes, removes from queue)
Img-2 ------------> Worker B  (processes, removes from queue)
Img-3 ------------> Worker C  (processes, removes from queue)
Img-4 ------------> Worker A  (Worker A finished, comes back for more)
Img-5 ------------> Worker B  (Worker B finished, comes back for more)

Real-world analogy: A shared to-do list where anyone can grab the next task, but once someone takes it, it is theirs.

Use when: You want to distribute work across multiple instances, where each unit of work should be done exactly once.

Topic (Publish-Subscribe Model)

A topic is used for event broadcasting. When you want every interested party to receive a copy of every event.

Rules:

• A message is delivered to every subscriber (or every consumer group)
• Each consumer group gets its own independent copy
• Adding a new subscriber does not affect existing subscribers
• Message may be retained for replay

Visual:

[Topic: order-placed]

OrderPlaced event-1 ---> Email Service Consumer Group      (processes its copy)
                    ---> Analytics Consumer Group           (processes its copy)
                    ---> Warehouse Consumer Group           (processes its copy)
                    ---> New SMS Service (added 6 months later, zero changes to producer)

Real-world analogy: A radio broadcast. Everyone tuned to the station hears the same broadcast. Adding new listeners does not affect the broadcast.

Use when: An event has occurred and multiple independent services need to react to it.

The Cheat Sheet

8. Communication Models

8.1 Point-to-Point

One producer, many competing consumers, each message processed by exactly one consumer.

Scenario: 10,000 image resize jobs need to be processed.
Solution: 50 worker instances, all listening on the same queue.

Producer:  Publishes 10,000 "ResizeImage" messages to the queue.
Workers:   Each grabs the next available message, processes it, ACKs it.
           Work is distributed automatically across all 50 workers.
           Adding more workers increases throughput linearly.

Key applications:

• Job queues and task distribution
• Order processing pipelines
• Data transformation workers
• Scheduled job distribution

8.2 Publish-Subscribe

One producer, multiple consumer groups, each group receives all messages independently.

Scenario: Every "UserRegistered" event must trigger:
          - A welcome email (Email Service)
          - An onboarding task (Onboarding Service)
          - A record in CRM (CRM Service)
          - An analytics event (Analytics Service)

Solution: Publish to "user-registered" topic. Each service subscribes independently.

Producer:  Publishes ONE "UserRegistered" event.
Consumers: All four services independently receive and process the same event.
           Adding a fifth service requires ZERO changes to the producer.

Key applications:

• Domain event broadcasting
• Event-driven microservices integration
• Audit and compliance logging
• Cache invalidation broadcasts
• Real-time data synchronization

9. Key Benefits

Benefit 1: Decoupling (The Most Valuable Benefit)

Without message queues, services are coupled to each other:

OrderService --> (directly calls) --> EmailService, WarehouseService, AnalyticsService

With message queues, services are coupled only to the message contract:

OrderService --> (publishes to) --> "order-placed" topic
EmailService <-- (subscribes to) -- "order-placed" topic
WarehouseService <-- (subscribes to) -- "order-placed" topic

Impact: You can change, replace, or redeploy any service without affecting others. You can add new consumers without touching the producer.

Benefit 2: Load Leveling

Message queues are natural traffic shock absorbers:

Normal day:     1,000 orders/hour  -> [Queue: 0 depth] -> Processing at 1,000/hr
Black Friday: 100,000 orders/hour  -> [Queue: grows]   -> Processing at 5,000/hr
After peak:     1,000 orders/hour  -> [Queue: drains]  -> Processing at 5,000/hr (clearing backlog)

Your downstream services never receive more traffic than they can handle. The queue absorbs spikes. This prevents cascading overload failures.

Benefit 3: Resilience and Fault Tolerance

• Consumer crashes without ACKing? Message is redelivered to another consumer.
• Email Service has a 2-hour outage? Messages accumulate. When it recovers, it processes the backlog.
• Network blip causes a failure? Automatic retry handles it.
• Multiple consumer instances? No single point of failure.

Benefit 4: Independent Scalability

Normal conditions:    OrderService (2 instances), EmailService (2 instances)
Email campaign day:   OrderService (2 instances), EmailService (20 instances)

Scale only what needs scaling. No coordination required between teams.
Auto-scaling based on queue depth is a standard pattern.

Benefit 5: Temporal Decoupling

Producer and consumer do not need to be available at the same time:

• Consumer can be taken offline for maintenance/deployment
• Messages queue up during the maintenance window
• Consumer comes back online and processes the backlog
• No messages are lost and no producer needs to know about the maintenance

Benefit 6: Natural Audit Trail

Message queues provide a chronological record of everything that has happened in your system:

• What events occurred, and in what order
• When did each event happen
• Who produced each event (via sourceService header)
• How long did it take to process each event

Kafka, in particular, retains messages for days or weeks, enabling full event replay.

10. When to Use and When to Avoid

Use Message Queues When:

1. Background job processing: Image resizing, PDF generation, video encoding, report generation - tasks where users can receive "we will notify you when done"
2. Event-driven integration between services: One service state change should trigger reactions in other services
3. Traffic spike absorption: Your system receives bursts of requests that would overwhelm downstream services
4. Fire-and-forget operations: Actions where you do not need immediate confirmation
5. Fan-out notifications: One event needs to trigger actions in multiple independent services
6. Audit and compliance logging: Immutable record of all state changes
7. Multi-step workflow orchestration: Business processes with multiple steps and failure handling
8. Data pipeline and ETL processing: Transforming and moving data between systems
9. IoT data ingestion: High-volume, continuous sensor data streams
10. Cache invalidation broadcasts: Telling all service instances to invalidate a cached item

Avoid Message Queues When:

1. Immediate response is required: "What is my account balance?" needs a real-time answer
2. Simple database CRUD: A basic create/read/update/delete operation does not need a queue
3. Strong transactional consistency is non-negotiable within one operation: Adding a queue introduces a potential window where state is inconsistent (address this with the Outbox pattern - see Part 4)
4. Single-service applications: Do not introduce message queue infrastructure for a monolith that does not need it
5. Ultra-low latency requirements: If you need sub-millisecond operations, queue overhead (network + storage) may be unacceptable
6. Real-time bidirectional communication: Use WebSockets or Server-Sent Events for live chat, live dashboards
7. High-frequency small lookups: "Is product X in stock?" - query a database or cache directly

The Decision Framework

Before introducing a message queue, ask these questions:

Q1: Does the producer need the result to complete its current operation?
    Yes  --> Use synchronous communication
    No   --> Continue to Q2

Q2: Does only ONE service need to process each message?
    Yes  --> Use a Queue (work distribution)
    No   --> Use a Topic (event broadcasting)

Q3: Does the order of processing matter strictly?
    Yes  --> Use FIFO Queue, or Kafka with single partition / partition key strategy
    No   --> Standard queue or multi-partition Kafka topic

Q4: Do you need to replay historical events?
    Yes  --> Use Kafka or another event-streaming platform with retention
    No   --> RabbitMQ, SQS, or other traditional message queues will work

Summary

Message queues solve the fundamental problem of tight coupling in distributed systems. They enable:

• Decoupling: Services communicate through message contracts, not direct APIs
• Resilience: Failures in one service do not cascade to others
• Scalability: Services scale independently based on their own needs
• Asynchrony: Users get fast responses; background work happens separately
• Durability: Messages survive failures and are reliably delivered

The two key models are:

• Queue (Point-to-Point): Work distribution - one message, one consumer
• Topic (Pub/Sub): Event broadcasting - one message, all subscribers

In Part 2, we go deep on messaging patterns - the design vocabulary you need to architect real systems.

Next: Part 2 - Messaging Patterns and Architecture
Index: Message Queues Demystified - Index