Membangun Bot Discord Skala Besar dengan Sharding dan Redis

Saat sebuah bot Discord mulai melayani ribuan guild aktif, arsitektur single-process monolithic akan cepat menemui bottleneck: memory bloat, event lag, hingga koneksi gateway yang terputus secara mendadak.

Mengapa Sharding Dibutuhkan?

Discord membatasi satu koneksi WebSocket (Gateway) hingga maksimal 2.500 guild. Ketika komunitas tumbuh melewati angka tersebut, bot harus membagi guild ke dalam beberapa proses terpisah yang disebut shards.

// index.js: Menginisialisasi ShardingManager
import { ShardingManager } from 'discord.js';

const manager = new ShardingManager('./bot.js', {
  token: process.env.DISCORD_TOKEN,
  totalShards: 'auto',
  respawn: true
});

manager.on('shardCreate', shard => {
  console.log(`[System] Shard #${shard.id} berhasil diluncurkan`);
});

manager.spawn();

Memisahkan Beban Berat ke Redis Worker

Salah satu kesalahan paling umum adalah mengeksekusi operasi I/O berat (seperti query analitik atau logging gambar ke cloud) langsung di dalam callback event command. Ini memblokir event loop Node.js dan menyebabkan jeda respons.

Gunakan antrean pesan seperti BullMQ dengan backend Redis:

// queue.ts: Worker terisolasi untuk tugas latar belakang
import { Queue, Worker } from 'bullmq';
import IORedis from 'ioredis';

const connection = new IORedis(process.env.REDIS_URL);
export const auditLogQueue = new Queue('auditLogs', { connection });

// Worker terpisah di proses background
const worker = new Worker('auditLogs', async job => {
  const { guildId, action, userId, metadata } = job.data;
  await saveAuditLogToPostgres(guildId, action, userId, metadata);
}, { connection });

Kesimpulan

Dengan memisahkan client gateway menggunakan sharding dan mendelegasikan tugas berat ke antrean Redis, bot dapat mempertahankan respon command di bawah 100ms dengan stabilitas uptime yang konsisten.