Event Streaming vs Message Queues

Event streaming vs message queues for modern systems

Event streaming and message queues both move data, but they model time and replay very differently. Choosing the wrong model makes it hard to scale, debug, or recover from incidents.

Prerequisites

• Node.js 20+
• Access to Kafka and RabbitMQ
• Familiarity with publish/subscribe patterns

Key conceptual differences

• Streaming treats events as an immutable log that can be replayed.
• Queues treat messages as transient work items.
• Streaming supports multiple independent consumers without data loss.
• Queues typically delete messages once acknowledged.

Node.js examples

Kafka streaming consumer:

import { Kafka } from "kafkajs";

const kafka = new Kafka({ clientId: "analytics", brokers: ["localhost:9092"] });
const consumer = kafka.consumer({ groupId: "analytics" });

await consumer.connect();
await consumer.subscribe({ topic: "orders", fromBeginning: true });

await consumer.run({
  eachMessage: async ({ message }) => {
    await processEvent(message.value?.toString());
  }
});

RabbitMQ queue consumer:

import amqp from "amqplib";

const connection = await amqp.connect("amqp://localhost");
const channel = await connection.createChannel();
await channel.assertQueue("orders", { durable: true });

channel.consume("orders", async msg => {
  if (!msg) {
    return;
  }

  await processJob(msg.content.toString());
  channel.ack(msg);
});

Decision guidance

• Choose streaming when you need replay, auditability, or multiple consumers.
• Choose queues when you need task distribution or request-reply.
• Use both when services need commands (queues) and facts (streams).

Things to remember

• Streaming emphasizes durable logs and replay.
• Queues emphasize work distribution and fast acknowledgments.
• The same system can sometimes support both, but the mental model still matters.