Belajar WebSocket - Horizontal Scaling dengan Redis Adapter

#Pendahuluan

Di episode 15 kalian meletakkan beberapa server di belakang load balancer. Tapi ada masalah besar: jika klien di server A mengirim pesan ke room, klien di server B tidak akan menerimanya — karena room hanya dikenal di memori server A.

Episode 16 membahas solusinya: Redis adapter. Dengan pola publish-subscribe, setiap instance Socket.IO menyebarkan event ke semua instance lain, sehingga room, namespace, dan broadcast bekerja seolah-olah satu server.

#Tantangan Scaling

#Masalah State Lokal

Socket.IO menyimpan room dan koneksi di memori setiap instance. Saat instance berbeda, informasi ini tidak saling melihat.

Masalah broadcast lintas instance

// instance A
io.to("game-1").emit("status", "dimulai");
// klien di instance B tidak menerima apa pun

io.to("game-1").emit(...) di instance A hanya menjangkau koneksi yang ada di memori instance A. Koneksi di instance B buta terhadap event ini. State seperti ini disebut state lokal atau in-memory state.

#Solusi: State Bersama

Semua instance harus berbagi informasi melalui penyimpanan bersama. Untuk broadcast real-time, mediumnya bukan database biasa — butuh sesuatu yang sangat cepat dengan pola publish-subscribe. Di situlah Redis masuk.

#Pola Pub/Sub

#Cara Kerja Pub/Sub

Redis Pub/Sub adalah pola satu-penerbit-banyak-pelanggan yang sangat sederhana.

Pub/Sub Redis dasar

const redis = require("redis");
 
const publisher = redis.createClient();
const subscriber = redis.createClient();
 
await subscriber.subscribe("saluran:game", (pesan) => {
  console.log("diterima:", pesan);
});
 
await publisher.publish("saluran:game", "event baru");

subscriber.subscribe(channel, fn) mendaftarkan pemanggil untuk saluran tertentu, dan publisher.publish(channel, pesan) menyebarkan pesan ke semua pelanggan saluran itu. Redis meneruskan pesan secepat mungkin tanpa menyimpannya.

#Kenapa Bukan Database Biasa

Database menulis dan membaca dengan query — terlalu lambat untuk event real-time. Pub/Sub Redis mengirim pesan secara langsung ke pelanggan dalam mikrodetik. Trade-off-nya: pesan Pub/Sub hilang jika tidak ada pelanggan, jadi hanya cocok untuk event real-time, bukan untuk persistence.

#Socket.IO Redis Adapter

#Pemasangan dan Konfigurasi

Adapter mengubah Socket.IO sehingga broadcast dikirim lewat Redis.

Install Redis adapter

bun add @socket.io/redis-adapter redis

Pasang adapter di server

const { createClient } = require("redis");
const { createAdapter } = require("@socket.io/redis-adapter");
 
const pubClient = createClient({ url: "redis://redis:6379" });
const subClient = pubClient.duplicate();
 
await Promise.all([pubClient.connect(), subClient.connect()]);
 
const io = new Server(server, {
  adapter: createAdapter(pubClient, subClient),
});

createAdapter(pubClient, subClient) membutuhkan dua koneksi Redis: satu untuk publish, satu untuk subscribe. Dengan adapter ini, io.to("game-1").emit(...) di instance mana pun akan disebar ke semua instance yang terhubung Redis yang sama.

#Yang Menjadi Otomatis

Setelah adapter terpasang, fitur berikut bekerja lintas instance tanpa perubahan kode:

Broadcast ke semua klien atau ke semua kecuali pengirim.
Room yang sama dikenali di semua instance.
Namespace tetap terisolasi tetapi terdistribusi.
Presence yang disiarkan sampai ke semua instance.

Kode aplikasi kalian tidak berubah — adapter bekerja transparan di bawah Socket.IO.

#Cluster Mode

Untuk Redis cluster dengan banyak node, gunakan konfigurasi khusus.

Adapter untuk Redis cluster

const { createCluster } = require("redis");
const { createClusterAdapter } = require("@socket.io/redis-adapter");
 
const redis = createCluster({
  rootNodes: [
    { url: "redis://redis-1:6379" },
    { url: "redis://redis-2:6379" },
  ],
});

createClusterAdapter(...) menangani banyak node Redis sekaligus. Ini berguna saat volume event sudah melebihi kapasitas satu Redis.

#Alternatif Adapter

#Bukan Hanya Redis

Beberapa adapter lain tersedia untuk kebutuhan berbeda.

Adapter Socket.IO yang tersedia

MongoDB   : memakai change stream, cocok saat Mongo sudah jadi basis utama
RabbitMQ  : memakai exchange fanout, bagus untuk integrasi broker yang ada
Kafka     : memakai topic, untuk event log berskala besar

Pilih adapter berdasarkan infrastruktur yang sudah dimiliki tim. Redis tetap paling populer karena ringan, cepat, dan mudah dipasang. Semua adapter mengimplementasikan antarmuka yang sama, jadi menggantinya tidak mengubah kode aplikasi.

#Pola Arsitektur

#Server Stateless

Dengan adapter, server menjadi hampir stateless: semua state koneksi berbagi lewat Redis.

Menambah instance secara bebas

const io = new Server(server, {
  adapter: createAdapter(pubClient, subClient),
});

Kode yang sama dijalankan di berapa pun instance. Menambah instance tinggal menjalankan container yang sama dan mendaftarkannya ke load balancer — tidak ada konfigurasi khusus per instance.

#Batasan yang Tersisa

Beberapa hal masih perlu perhatian:

Autentikasi: verifikasi token bisa dilakukan di setiap instance secara mandiri.
Presence persisten: status pengguna yang bertahan butuh penyimpanan Redis terpisah, bukan sekadar pub/sub.
Rate limit lintas instance: counter harus di Redis, seperti dibahas di episode 13.
Message queue offline: antrean butuh penyimpanan, bukan pub/sub.

#Penutup

Episode 16 membuka jalan menuju skala horizontal: dengan Redis adapter, room dan broadcast tidak lagi terbatas pada satu instance, dan server bisa ditambah sesuka hati tanpa mengubah kode.

Inti yang harus dibawa pulang:

Room di memori hanya dikenal instance sendiri, jadi broadcast tidak lintas instance.
Redis Pub/Sub menyebarkan event ke semua pelanggan dengan cepat.
Redis adapter membuat room, namespace, dan broadcast bekerja lintas instance.
Dibutuhkan dua koneksi Redis: satu publish, satu subscribe.
Adapter lain seperti MongoDB, RabbitMQ, dan Kafka tersedia sebagai alternatif.
Presence, rate limit, dan queue tetap butuh penyimpanan persisten di Redis.

Di episode 17 berikutnya kita membahas performance optimization: optimasi koneksi dan pesan, clustering Node.js, pengaturan event loop, serta optimasi jaringan dan klien.