صف Redis در برابر Kafka برای گزارش‌سازی شبانه

«برای گزارش شبانه، کافکا لازم داریم؟» — سؤالی که در جلسات معماری بارها شنیده‌ایم و جوابش به شکل‌دهی کار بستگی دارد، نه به محبوبیت ابزار.

دو الگوی متمایز

الگوی صف ساده (Redis Lists / BullMQ): تولیدکننده، task را push می‌کند؛ worker آن را pop می‌کند. وضعیت در حافظه، سرعت بالا، پخش‌بندی (partitioning) ندارد.

الگوی لاگ بازپخش‌پذیر (Kafka): رویدادها در پارتیشن‌های ماندگار می‌مانند؛ چند مصرف‌کننده می‌توانند مستقل از هم، دوباره از ابتدا بخوانند.

// الگوی صف: ساده و سریع — مناسب jobهای idempotent شبانه
import { Queue, Worker } from "bullmq";

export const reportQueue = new Queue("nightly-reports", { connection: redis });
await reportQueue.addBulk(
  dailyBatches.map((batch) => ({
    name: "build-report",
    data: { batchId: batch.id },
    opts: { attempts: 3, backoff: { type: "exponential", delay: 5000 } },
  })),
);

new Worker("nightly-reports", async ({ data }) => buildReport(data.batchId), {
  connection: redis,
  concurrency: 8,
});

کی Redis کافی است

• کار idempotent باشد (اجرای دوباره بی‌خطر).
• حجم: ده‌ها هزار task در دقیقه، نه میلیون‌ها در ثانیه.
• نیازی به «بازخوانی تاریخچه توسط مصرف‌کننده جدید» نباشد.

کی Kafka لازم می‌شود

• چند تیم/سرویس روی همان جریان رویداد مستقل مصرف می‌کنند.
• باید بتوان سال گذشته را دوباره پخش کرد (بازمحاسبه).
• ترتیب دقیق per-key و ماندگاری طولانی‌مدت شرط است.

# بازپخش یک بازه قدیمی در Kafka (برای بازمحاسبه گزارش)
kafka-console-consumer --bootstrap-server kafka:9092   --topic nightly-events   --from-beginning   --max-messages 50000

نتایج اندازه‌گیری‌شده روی سامانه گزارش ماه

سناریو	Redis/BullMQ	Kafka
۵۰ هزار task شبانه	۴ دقیقه	۳ دقیقه
راه‌اندازی اولیه زیرساخت	چند دقیقه (موجود)	سرویس‌های جدید
بازمحاسبه ۳۰ روز گذشته	بازنویسی دستی	بازپخش خودکار
پیچیدگی عملیاتی	کم	متوسط تا زیاد

نتیجه‌گیری

برای گزارش شبانه‌ای که یک بار در شب اجرا می‌شود، صف Redis انتخاب درست و کم‌هزینه‌ای است. Kafka زمانی به میدان می‌آید که «رویداد» خودش داده ارزشمندی باشد که چند مصرف‌کننده دارد — نه فقط یک لیست کار.