Lesson 6 of 15Message Queue Deep Dive

Message Queue Deep Dive

A queue is not just a list of jobs. In a notification platform, it is the shock absorber between product traffic and provider capacity.

Core Terms

TermMeaning
ProducerCode that publishes a message
BrokerQueue server or managed queue service
TopicNamed stream or category of messages
ConsumerWorker that reads messages
OffsetPosition in a stream
Consumer groupGroup of consumers sharing work
RetryReprocessing after failure
Back pressureQueue grows faster than workers process
DLQDead-letter queue for failed messages

Technology Comparison

ToolBest ForStrengthTrade-off
BullMQNode.js Redis-backed jobsSimple delayed retriesRedis ops
RabbitMQRouting and work queuesMature routingCluster tuning
KafkaHigh-throughput event streamsReplay and durabilityComplexity
Redis StreamsLightweight streamingSimple and fastFewer guarantees
AWS SQSManaged cloud queuesNo server to manageCloud limits
SidekiqRuby background jobsBattle-testedRuby ecosystem

For a personal SaaS or startup, BullMQ or SQS can be enough. For an event platform at marketplace scale, Kafka may be justified.

Queue Design for Notifications

notification-high-prioritynotification-transactionalnotification-marketingnotification-dlq

Do not put OTP, password-change alerts, and marketing campaigns in one queue forever. If marketing floods the queue, security alerts should not wait behind it.

Retry Strategy

await queue.add("send-email", payload, {
  attempts: 5,
  backoff: {
    type: "exponential",
    delay: 10_000
  },
  removeOnComplete: true,
  removeOnFail: false
});

Retry only failures that can recover. A provider timeout can recover. An invalid email address probably cannot. Classify errors.

Failure TypeExamples
RetryableNetwork timeout, provider 429, provider 500
Non-retryableInvalid recipient, unsubscribed user, invalid template variables

Dead Letter Queue

A DLQ is where messages go when normal processing cannot finish.

Process flow4 steps
  1. 01
    Worker fails job 5 times
  2. 02
    Move to notification-dlq
  3. 03
    Alert engineering or operations
  4. 04
    Inspect, fix, replay, or discard

A DLQ is not a trash can. It is an operational queue that needs ownership, dashboards, and replay tooling.

Ordering

Some notifications need order. "Order shipped" should not arrive before "Order confirmed." Kafka partitions can preserve ordering per key, such as orderId. BullMQ queues process jobs in order only under specific concurrency conditions. SQS FIFO can preserve group ordering with throughput limits.

If strict ordering is required, define the ordering key.

Ordering key
order_id
Sequence
OrderConfirmed -> PaymentCaptured -> PackageShipped -> Delivered

Back Pressure

Back pressure means incoming jobs exceed processing capacity.

Incoming
10,000 jobs/minute
Processing
4,000 jobs/minute
Queue growth
6,000 jobs/minute

You can respond by scaling workers, reducing marketing sends, routing to another provider, or temporarily delaying low-priority queues.

Common Mistakes

  1. Choosing Kafka because it sounds senior.
  2. Not separating high-priority and bulk queues.
  3. Retrying permanent failures.
  4. Having no DLQ replay tool.
  5. Forgetting provider rate limits while scaling consumers.

Interview Questions

  1. When would you choose Kafka over SQS?
  2. What is a dead-letter queue?
  3. How do consumer groups improve throughput?
  4. How do you handle back pressure?

Exercise

Design queue names and retry policies for OTP, invoice email, and promotional campaign notifications.

What you will learn

How queue concepts map to notification delivery.

When to choose Kafka, RabbitMQ, Redis Streams, SQS, or BullMQ.

How retries, back pressure, offsets, and DLQs work.

How ordering and throughput affect channel design.

Production checklist

  • Queue technology matches scale
  • Retry policy is explicit
  • DLQ exists
  • Consumer group strategy is clear
  • Back pressure is monitored
  • Ordering needs are documented