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

Term            Meaning
Producer        Code that publishes a message
Broker          Queue server or managed queue service
Topic           Named stream or category of messages
Consumer        Worker that reads messages
Offset          Position in a stream
Consumer group  Group of consumers sharing work
Retry           Reprocessing after failure
Back pressure   Queue grows faster than workers process
DLQ             Dead-letter queue for failed messages

Technology Comparison

Tool           Best For                         Strength                 Trade-off
BullMQ         Node.js Redis-backed jobs         simple delayed retries   Redis ops
RabbitMQ       routing and work queues           mature routing           cluster tuning
Kafka          high-throughput event streams     replay and durability    complexity
Redis Streams  lightweight streaming             simple and fast          fewer guarantees
AWS SQS        managed cloud queues              no server to manage      cloud limits
Sidekiq        Ruby background jobs              battle-tested            Ruby 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-priority
notification-transactional
notification-marketing
notification-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.

Retryable:
  - network timeout
  - provider 429
  - provider 500

Non-retryable:
  - invalid recipient
  - unsubscribed user
  - invalid template variables

Dead Letter Queue

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

Worker fails job 5 times
  |
  v
Move to notification-dlq
  |
  v
Alert engineering or operations
  |
  v
Inspect, fix, replay, or discard

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:
  1. OrderConfirmed
  2. PaymentCaptured
  3. PackageShipped
  4. 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.