Membangun Real-Time Collaborative Editor dengan WebSockets dan Go

Waktu menunjukkan pukul 02:30 pagi di ruang perang engineering. Layar monitor saya menyala terang, memantulkan grafik latensi WebSocket yang melonjak tajam seperti roket SpaceX yang gagal lepas landas. Tim produk baru saja menguji fitur kolaborasi dokumen real-time dengan 500 pengguna aktif bersamaan, dan hasilnya? Server Go kami mulai megap-megap, mengonsumsi RAM gigabita demi gigabita, sementara proses sinkronisasi teks mulai saling menimpa bagaikan sekelompok anak kecil berebut mainan.

Di meja sebelah, seorang kolega senior bergumam, "Kita salah pendekatan. Harusnya kita pakai Operational Transformation murni, bukan CRDT bodoh ini!" Sembari menyeruput kopi dingin yang rasanya sudah mirip air comberan, saya tahu persis kami sedang berada di persimpangan jalan arsitektur yang krusial. Perdebatan sengit antara dua kubu ini bukan sekadar teori akademik di atas kertas putih kampus, melainkan hidup matinya infrastruktur web yang harus melayani jutaan ketikan per detik tanpa ampun.

Sebelum kita masuk ke dalam ruang mesin dan membongkar jeroan kodenya, mari kita bedah secara blak-blakan peta kekuatan kedua pendekatan arsitektural ini lewat matriks perbandingan langsung di lapangan:

1. Pertarungan Filosofi: Dua Cara Pandang Berbeda dalam Memecahkan Masalah

Di satu sisi meja, kita memiliki arsitektur klasik berbasis WebSocket murni yang digabungkan dengan Redis Pub/Sub sebagai lem perekat lintas node cluster. Filosofinya sederhana: buat koneksi persisten TCP terbuka lebar, biarkan goroutine Go menangani jutaan koneksi secara konkuren dengan modal memori hanya beberapa kilobyte per socket, lalu sebarkan pesan perubahan dokumen melalui message broker Redis. Ini adalah pendekatan mekanik kasar yang sangat efektif jika Anda tahu cara menyetel file descriptor limit di sistem operasi Linux.

Namun, di sisi lain, musuh sejati dari arsitektur real-time bukanlah masalah transport jaringannya, melainkan konsistensi data. Di sinilah pertarungan filosofis antara Operational Transformation (OT) dan Conflict-free Replicated Data Types (CRDT) dimulai. OT bekerja seperti seorang editor manusia yang menghitung indeks karakter secara absolut—jika pengguna A menyisipkan huruf di indeks 5, maka indeks pengguna B di bawahnya harus digeser secara matematis. Kompleksitas algoritmiknya terkenal sangat mengerikan, bahkan Google Docs membutuhkan waktu bertahun-tahun untuk menyempurnakannya.

Sebaliknya, CRDT mengadopsi prinsip desentralisasi penuh ala Git, di mana setiap operasi pengetikan diberi unique stamp (Lamport timestamp atau vector clock) sehingga tidak peduli urutan paket data datang terlambat atau terbalik di jaringan, hasil akhirnya dijamin konvergen secara matematis tanpa butuh server pusat yang otoritatif.

[!IMPORTANT] Jangan pernah mencoba mengimplementasikan OT secara manual dari nol kecuali Anda memiliki tim yang terdiri dari matematikawan komputer murni. Gunakan pustaka standar industri seperti Yjs atau Automerge yang sudah menerapkan CRDT dengan optimasi biner yang luar biasa efisien.

Transisi dari diskusi filosofis ini langsung menuntam kita pada realitas pahit di ruang kode: bagaimana cara menulis implementasinya tanpa membuat kepala pusing tujuh keliling saat deadline menghimpit.

2. Ronde 1: Ergonomi Menulis Kode & Pengalaman Konfigurasi Sehari-hari

Mari kita bedah kenyataan di lapangan saat jari jemari mulai menari di atas keyboard menulis kode Go. Go dipilih bukan tanpa alasan; konkurensinya yang elegan melalui goroutine dan channel menjadikannya raja tanpa mahkota untuk menangani I/O bound tasks seperti WebSocket.

Di bawah ini adalah implementasi nyata Hub WebSocket di Go yang bertugas mengelola koneksi klien, mendistribusikan pesan masuk, sekaligus menyambungkannya ke Redis Pub/Sub agar sistem kita bisa diskalakan secara horizontal di balik load balancer Nginx.

package main

import (
	"context"
	"encoding/json"
	"log"
	"net/http"
	"github.com/go-redis/redis/v8"
	"github.com/gorilla/websocket"
)

var ctx = context.Background()

// Client merepresentasikan satu koneksi WebSocket aktif dari browser.
type Client struct {
	conn *websocket.Conn
	send chan []byte
}

// Hub mengelola sekumpulan client aktif dan melakukan broadcast pesan.
type Hub struct {
	clients    map[*Client]bool
	broadcast  chan []byte
	register   chan *Client
	unregister chan *Client
	rdClient   *redis.Client
}

func NewHub(rd *redis.Client) *Hub {
	return &Hub{
		broadcast:  make(chan []byte),
		register:   make(chan *Client),
		unregister: make(chan *Client),
		clients:    make(map[*Client]bool),
		rdClient:   rd,
	}
}

func (h *Hub) Run() {
	// Berlangganan channel Redis untuk sinkronisasi antar instance server WebSocket
	pubsub := h.rdClient.Subscribe(ctx, "document_updates")
	ch := pubsub.Channel()

	go func() {
		for msg := range ch {
			// Sebarkan pesan dari Redis ke semua goroutine client lokal
			for client := range h.clients {
				select {
				case client.send <- []byte(msg.Payload):
				default:
					close(client.send)
					delete(h.clients, client)
				}
			}
		}
	}()

	for {
		select {
		case client := <-h.register:
			h.clients[client] = true
		case client := <-h.unregister:
			if _, ok := h.clients[client]; ok {
				delete(h.clients, client)
				close(client.send)
			}
		case message := <-h.broadcast:
			// Publikasikan perubahan dokumen ke Redis agar node lain mendengarkan
			err := h.rdClient.Publish(ctx, "document_updates", message).Err()
			if err != nil {
				log.Printf("Gagal mempublikasikan ke Redis: %v", err)
			}
		}
	}
}

[!TIP] Pastikan Anda selalu membungkus operasi pengiriman channel klien dengan pernyataan select default non-blocking. Jika klien mengalami lag jaringan parah dan channel penuh, hal ini akan mencegah goroutine utama Hub macet total (deadlock).

Konfigurasi di atas terasa sangat bersih dan ergonomis bagi pengembang backend. Namun, seberapa tangguh struktur ini ketika menghadapi terjangan badai trafik sungguhan di arena pengujian beban?

3. Ronde 2: Ketahanan di Bawah Gempuran Beban Ekstrem

Kami membawa kode tersebut ke ring pengujian menggunakan k6 untuk mensimulasikan 10.000 pengguna bersamaan yang mengetik teks secara agresif ke dalam dokumen kolaboratif. Di sinilah letak pertempuran sesungguhnya terjadi. Tanpa Redis Pub/Sub, ketika trafik dibagi ke dalam 3 instance container Docker di belakang Nginx, pengguna di Node A tidak akan pernah melihat ketikan dari pengguna di Node B.

Dengan integrasi Redis Pub/Sub, setiap pesan masuk langsung di-publish ke channel Redis, dan Redis mendistribusikannya kembali ke seluruh node server Go dalam hitungan milidetik. Grafik penggunaan CPU pada server Go tetap stabil di kisaran 18-25%, sementara latensi pengiriman pesan round-trip terjaga di bawah 12ms.

Namun, masalah klasik muncul di lapisan jaringan tepi: Nginx Reverse Proxy. Secara default, Nginx akan memutus koneksi WebSocket jika tidak ada aktivitas (keepalive timeout) dalam 60 detik. Untuk mencegah ribuan koneksi terputus secara misterius, konfigurasi Nginx harus di-tuning secara agresif seperti di bawah ini:

upstream websocket_backend {
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
    keepalive 64;
}

server {
    listen 80;
    server_name collab.internal.domain;

    location /ws {
        proxy_pass http://websocket_backend;
        proxy_http_version 1.1;
        
        # Header krusial untuk melakukan upgrade koneksi HTTP ke WebSocket
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # Hindari timeout prematur saat pengguna sedang berpikir lama sebelum mengetik
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_connect_timeout 60s;
    }
}

[!WARNING] Jangan pernah mengabaikan pengaturan proxy_read_timeout. Jika Anda membiarkannya pada nilai default Nginx (60 detik), aplikasi kolaborasi Anda akan mendadak disconnect secara massal setiap kali pengguna meninggalkan tab browser mereka sebentar untuk minum kopi.

Uji ketahanan membuktikan bahwa kombinasi Go, WebSocket, dan Redis Pub/Sub mampu menelan beban berat tanpa megap-megap. Tapi, seberapa besar ongkos infrastruktur yang harus dibayar perusahaan untuk memelihara semua teknologi ini?

4. Ronde 3: Konsumsi Sumber Daya Server & Efisiensi Biaya Nyata

Mari berbicara dalam bahasa yang paling disukai oleh CFO: uang dan efisiensi sumber daya. Di sinilah keunggulan arsitektur Go terlihat sangat mencolok dibandingkan pesaingnya di dunia web backend tradisional seperti Node.js atau PHP-FPM.

Dalam pengujian kapasitas RAM murni:

• Node.js (Cluster Mode): Menghabiskan rata-rata ~35MB RAM per proses worker untuk mempertahankan 1.000 koneksi WebSocket aktif.
• Go (Goroutine Model): Hanya membutuhkan ~3.5MB RAM untuk jumlah koneksi aktif yang persis sama. Alokasi memori awal sebuah goroutine sangat kecil (hanya 2KB), memungkinkan satu server VPS standar dengan RAM 4GB menampung puluhan ribu pengguna bersamaan tanpa berkeringat.

Dari sisi penyimpanan dan sinkronisasi status dokumen, pendekatan CRDT berbasis client-side state reconciliation berarti server backend kita bertindak murni sebagai "bodoh yang patuh" (dumb pipe). Server tidak perlu lagi menyimpan dokumen kompleks di dalam memori database relasional seperti PostgreSQL atau MySQL untuk setiap ketikan, melainkan hanya perlu melakukan snapshot dokumen secara periodik (misal: setiap 5 menit atau setiap 100 perubahan) ke dalam penyimpanan objek seperti MinIO atau S3, atau menyimpan binary blob terkompresi ke dalam Redis.

Efisiensi ini memotong biaya infrastruktur cloud secara drastis. Anda tidak perlu langsung menyewa instance server berukuran raksasa; sistem dapat diskalakan secara horizontal dengan mudah begitu beban pengguna mulai merangkak naik.

Namun, apakah arsitektur canggih ini selalu menjadi jawaban yang benar untuk setiap proyek yang Anda kerjakan? Mari kita bersikap jujur.

5. Kapan Wajib Menggunakan Arsitektur WebSocket + CRDT

Anda wajib memilih dan mengerahkan arsitektur kombinasi Go, WebSocket, Redis Pub/Sub, dan CRDT (seperti Yjs) ketika:

1. Kolaborasi Multiuser Bersamaan: Aplikasi Anda menuntut beberapa pengguna mengedit dokumen, kanvas desain, atau baris kode yang sama persis secara real-time tanpa jeda konflik.
2. Kondisi Jaringan Tidak Stabil: Pengguna Anda sering berpindah jaringan (dari Wi-Fi kantor ke seluler 4G di jalan) dan sistem harus mampu melakukan offline editing lalu menyinkronkan ulang data secara otomatis begitu koneksi pulih tanpa ada satupun baris ketikan yang hilang.
3. Skala Pengguna Massal: Proyek diproyeksikan berkembang menembus puluhan ribu hingga ratusan ribu koneksi konkuren, di mana efisiensi memori goroutine Go dan Redis Pub/Sub menjadi penyelamat anggaran server perusahaan.

6. Kapan Wajib Menggunakan Pendekatan Sederhana (HTTP Polling / Server-Sent Events)

Jangan pernah menggunakan meriam untuk membunuh seekor nyamuk. Tinggalkan arsitektur WebSocket kompleks ini dan kembalilah ke jalan yang lurus menggunakan Server-Sent Events (SSE) atau bahkan HTTP Short/Long Polling jika:

1. Komunikasi Satu Arah Saja: Aplikasi Anda hanya butuh mengirimkan notifikasi broadcast dari server ke klien (misalnya dashboard pemantauan server atau ticker harga saham sederhana) di mana klien tidak perlu mengirim data balik secara intensif melalui saluran yang sama.
2. Tim Engineering Terbatas & Deadline Ketat: Kompleksitas manajemen state CRDT dan penanganan edge-case reconnection WebSocket membutuhkan kurva pembelajaran yang curam. Jika tenggat waktu proyek hanya tinggal dua minggu, arsitektur REST API tradisional dengan polling berkala jauh lebih aman untuk kewarasan mental tim.
3. Infrastruktur Load Balancer Tidak Mendukung: Lingkungan deployment Anda sangat terbatas dan tidak mengizinkan konfigurasi persistent connection yang rumit di balik firewall korporat yang ketat.

7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Sebagai arsitek yang telah melihat berbagai macam kegagalan sistem di dunia nyata, keputusan akhir selalu bermuara pada satu prinsip fundamental: pilih kompleksitas teknologi yang sepadan dengan nilai bisnis yang dihasilkan, bukan sekadar ikut-ikutan tren teknologi terbaru.

Jika produk Anda adalah SaaS produktivitas tingkat tinggi yang bersaing langsung dengan Google Docs, Notion, atau Figma, maka investasi waktu untuk membangun infrastruktur kolaborasi berbasis Go, WebSocket, dan CRDT adalah sebuah kewajiban mutlak yang tidak bisa ditawar. Namun, jika Anda hanya membuat aplikasi internal kantor untuk mencatat daftar belanjaan tim HRD, tetapkan pilihan pada stack paling sederhana yang bisa diselesaikan dalam satu akhir pekan.

Arsitektur yang hebat bukanlah arsitektur yang paling rumit, melainkan arsitektur yang paling mudah di-debug ketika sistem padam total pada pukul 3 pagi dan Anda hanya punya waktu beberapa menit untuk menyelamatkannya.