Membangun Real-Time LLM Streaming Gateway dengan Golang dan SSE

Pukul 2 pagi di ruang server, tatapan saya terpaku pada grafik Grafana yang menunjukkan lonjakan memori tak terkendali. Kami baru saja meluncurkan fitur AI Assistant berbasis Large Language Model, dan ribuan pengguna secara bersamaan meminta respons real-time. Di satu sisi, tim produk mendesak latensi di bawah 100 milidetik; di sisi lain, infrastruktur kami mulai megap-megap menghadapi koneksi persisten. Perdebatan sengit pun pecah di antara para Senior Staff Engineer: apakah kita harus merombak total sistem menggunakan WebSocket berbasis Node.js yang fleksibel dua arah, atau tetap memegang prinsip arsitektur asinkron satu arah menggunakan Golang dan Server-Sent Events (SSE)? Ini bukan sekadar memilih library, melainkan pertarungan filosofi arsitektur web modern yang menentukan hidup matinya layanan produksi kita.

[!IMPORTANT] Memilih protokol real-time untuk LLM streaming tidak boleh disamakan dengan aplikasi chat biasa. Model bahasa besar mengirimkan aliran token (token stream) secara kontinu dengan ukuran paket kecil namun frekuensi tinggi, yang menuntut efisiensi buffer tingkat ekstrem pada level transport layer.

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

Diskusi di ruang arsitek berpusat pada satu pertanyaan fundamental: apakah kita membutuhkan komunikasi dua arah (bidirectional) yang ditawarkan oleh WebSocket, atau komunikasi satu arah (unidirectional) yang bersih dari Server-Sent Events (SSE)? Tim pengembang frontend sering kali mendorong WebSocket karena 'semua orang menggunakannya untuk chat'. Namun sebagai Infrastructure Engineer yang terbiasa mengelola Nginx, Cloudflare CDN, WAF, dan backends berbasis PHP serta Go, saya tahu persis bahwa WebSocket membawa beban operasional tersembunyi.

WebSocket membutuhkan protokol handshake khusus, manajemen frame masking, dan penanganan heartbeat (ping/pong) manual di aplikasi layer. Ketika koneksi terputus di balik load balancer, proses rekoneksi sering kali memicu thundering herd problem. Sebaliknya, SSE berjalan di atas protokol HTTP standar (HTTP/1.1 atau HTTP/2). Ini artinya kita bisa memanfaatkan infrastruktur web yang sudah matang: Nginx atau Caddy sebagai reverse proxy, Cloudflare Edge Caching, pembatasan rate limiting berbasis IP, hingga inspeksi WAF tanpa modifikasi rumit.

Filosofi Golang sangat selaras dengan kebutuhan ini: kompiler yang menghasilkan binary mandiri, pengelolaan memori langsung melalui model concurrency Goroutine yang hanya memakan sekitar 2KB per stack awal, serta pustaka standard net/http yang sangat optimal. Ketika dipadukan dengan SSE, kita mendapatkan jalur pipa data (data pipeline) dari upstream LLM API (seperti OpenAI atau vLLM internal) langsung ke browser klien tanpa hambatan.

Transisi mulus dari perdebatan filosofis ini langsung membawa kita ke meja kerja, di mana baris kode pertama mulai ditulis dan diuji ketahanannya terhadap realita deadline proyek.

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

Menulis kode di Node.js terasa sangat instan. Hanya butuh beberapa baris menggunakan Express dan ws, endpoint streaming langsung aktif. Namun, kemudahan ini harus dibayar mahal saat masuk tahap debugging production. Di sisi lain, Golang menuntut kedisiplinan tinggi sejak awal. Anda harus mendefinisikan struct, menangani tipe data secara ketat, dan mengelola pembatalan konteks (context cancellation) ketika klien tiba-tiba menutup tab browser di tengah proses streaming.

Mari kita bedah implementasi inti dari Golang SSE Gateway yang dirancang untuk menangani koneksi klien, membaca token dari channel internal, dan memastikan memori tidak bocor.

package main

import (
	"context"
	"fmt"
	"log"
	"net/http"
	"time"
)

// LLMGateway menangani koneksi client dan melakukan streaming SSE
func LLMStreamHandler(w http.ResponseWriter, r *http.Request) {
	// Pastikan browser mendefinisikan header SSE dengan benar
	fler, ok := w.(http.Flusher)
	if !ok {
		http.Error(w, "Streaming unsupported!", http.StatusInternalServerError)
		return
	}

	w.Header().Set("Content-Type", "text/event-stream")
	w.Header().Set("Cache-Control", "no-cache")
	w.Header().Set("Connection", "keep-alive")
	w.Header().Set("Access-Control-Allow-Origin", "*")

	ctx := r.Context()
	
	// Simulasi token stream dari LLM backend (misal: vLLM / OpenAI API)
	tokenStream := simulateLLMUpstream(ctx, "Jelaskan arsitektur microservices dalam 3 kalimat.")

	for {
		select {
		case <-ctx.Done():
			// Klien terputus (client disconnected), hentikan proses untuk hemat resource
			log.Println("Klien memutuskan koneksi secara prematur")
			return
		case token, open := <-tokenStream:
			if !open {
				// Sinyal selesai dari LLM upstream
				fmt.Fprintf(w, "data: [DONE]\n\n")
				fler.Flush()
				return
			}
			
			// Kirim token ke klien web via SSE format
			fmt.Fprintf(w, "data: %s\n\n", token)
			fler.Flush()
		}
	}
}

func simulateLLMUpstream(ctx context.Context, prompt string) <-chan string {
	ch := make(chan string)
	go func() {
		defer close(ch)
		tokens := []string{"Arsitektur", " microservices", " memecah", " aplikasi", " monolitik", " menjadi", " layanan-layanan", " kecil", " yang", " independen."}
		for _, t := range tokens {
			select {
			case <-ctx.Done():
				return
			time.Sleep(100 * time.Millisecond)
			ch <- t
		}
	}
	}()
	return ch
}

func main() {
	http.HandleFunc("/api/v1/stream", LLMStreamHandler)
	log.Println("SSE Gateway berjalan pada port :8080...")
	if err := http.ListenAndServe(":8080", nil); err != nil {
		log.Fatalf("Server error: %v", err
	)}
}

[!TIP] Penggunaan http.Flusher sangat krusial dalam SSE. Tanpa pemanggilan fler.Flush() secara eksplisit setelah setiap fmt.Fprintf, web server (atau reverse proxy seperti Nginx di depannya) akan menahan (buffer) data tersebut di memori hingga buffer penuh, yang menyebabkan pengalaman 'streaming' terasa patah-patah di sisi pengguna.

Konfigurasi Nginx di depan gateway ini juga memerlukan penyesuaian khusus agar tidak memicu buffering timeout:

location /api/v1/stream {
    proxy_pass http://localhost:8080;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    
    # Nonaktifkan buffering Nginx untuk SSE
    proxy_buffering off;
    proxy_cache off;
    chunked_transfer_encoding on;
    
    # Set timeout lebih lama untuk proses LLM yang berat
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
}

Dari kenyamanan penulisan kode dan konfigurasi proxy ini, kita melangkah ke arena pengujian sesungguhnya di bawah tekanan beban tinggi.

3. Ronde 2: Uji Ketahanan di Bawah Gempuran Beban Ekstrem

Teori arsitektur selalu terlihat sempurna di atas kertas putih. Namun, pertarungan yang sebenarnya terjadi ketika skrip pengujian beban menggunakan k6 atau wrk dilepas untuk membombardir endpoint /api/v1/stream dengan 5.000 koneksi konkuren secara simultan.

Kami mensimulasikan skenario di mana ribuan pengguna bersamaan menekan tombol 'Generate' pada aplikasi web mereka. Pada implementasi Node.js, V8 Garbage Collector mulai menunjukkan jeda (GC pauses) yang signifikan ketika heap memory membengkak di atas 1.5GB akibat alokasi buffer string yang masif untuk setiap socket. Latency p99 melonjak drastis hingga melampaui 800ms.

Sebaliknya, implementasi Golang menunjukkan performa yang jauh lebih stabil. Karena Goroutine bekerja dengan cooperative scheduling di atas thread OS yang terbatas, penanganan 10.000 koneksi SSE aktif hanya mencatatkan penggunaan CPU yang moderat tanpa lonjakan latency yang mengkhawatirkan.

Namun, ada musuh tersembunyi dalam arsitektur real-time: Rate Limiting. Tanpa perlindungan yang tepat, satu bot jahat dapat menghabiskan kuota token API LLM upstream dalam hitungan detik. Di sinilah integrasi Redis sebagai distributed rate limiter menjadi benteng pertahanan lini pertama.

package main
import (
	"context"
	"fmt"
	"net/http"
	"time"
)

// Dummy Redis check untuk rate limiting berbasis Token Bucket
func CheckRateLimit(clientIP string) bool {
	// Di implementasi nyata, gunakan go-redis/redisv9 dengan perintah EVAL (Lua Script)
	// untuk memastikan operasi atomic pengambilan kuota token.
	return true 
}

func RateLimitedMiddleware(next http.HandlerFunc) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		clientIP := r.RemoteAddr
		if !CheckRateLimit(clientIP) {
			http.Error(w, "Rate limit exceeded. Coba beberapa saat lagi.", http.StatusTooManyRequests)
			return
		}
		next(w, r)
	}
}

Uji ketahanan membuktikan bahwa ketahanan jaringan dan manajemen memori berjalan beriringan. Mari kita lihat lebih dalam bagaimana manajemen memori buffer token dikelola secara efisien.

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

Di dunia infrastruktur enterprise, performa tanpa efisiensi biaya adalah bencana finansial. Setiap gigabyte RAM tambahan di cloud server berbayar (AWS EC2, Google Cloud, atau DigitalOcean droplets) berarti penambahan anggaran bulanan yang signifikan.

Dalam pengujian konsumsi sumber daya server:

1. Node.js Gateway: Membutuhkan sekitar 25MB hingga 40MB per 1.000 koneksi aktif idle, dan melonjak hingga 350MB saat streaming aktif karena alokasi buffer V8 engine.
2. Golang SSE Gateway: Hanya mengonsumsi sekitar 4MB hingga 8MB per 1.000 koneksi aktif, dengan footprint total memori konstan di kisaran 45MB bahkan saat melayani 10.000 klien secara bersamaan.

Efisiensi ini berasal dari bagaimana Go mengelola alokasi memori heap dan kemampuan menghindari garbage collection pressure melalui penggunaan sync.Pool untuk objek buffer string yang sering digunakan berulang kali.

var bufferPool = sync.Pool{
	New: func() interface{} {
		return new(bytes.Buffer)
	},
}

func getBuffer() *bytes.Buffer {
	return bufferPool.Get().(*bytes.Buffer)
}

func putBuffer(buf *bytes.Buffer) {
	buf.Reset()
	bufferPool.Put(buf)
}

Dengan teknik pooling ini, alokasi memori baru di dalam loop streaming dapat ditekan seminimal mungkin, menjaga Garbage Collector Golang tetap tenang dan latency tetap konsisten di bawah 20ms.

Memahami efisiensi ini menuntun kita pada pemetaan keputusan yang jelas: kapan teknologi ini harus digunakan, dan kapan kita harus mencari alternatif lain.

5. Kapan Wajib Menggunakan Golang dan SSE Gateway

Anda wajib memilih kombinasi Golang dan Server-Sent Events (SSE) ketika:

• Arus Data Satu Arah (Unidirectional): Aplikasi Anda murni mengirimkan aliran data dari server ke klien, seperti LLM text generation, live stock ticker, notification feed, atau log streaming real-time.
• Skala Jutaan Koneksi Konkuren (High Concurrency): Infrastruktur dibatasi oleh anggaran server, di mana efisiensi RAM dan CPU per koneksi menjadi faktor penentu utama ROI perusahaan.
• Standar Web HTTP Standar: Lingkungan produksi Anda dilindungi oleh WAF, Cloudflare CDN, dan load balancer konvensional yang sudah dioptimalkan untuk lalu lintas HTTP/1.1 dan HTTP/2 tanpa perlu konfigurasi khusus upgrade protokol WebSocket.
• Infrastruktur Berbasis Microservices: Tim backend Anda sudah terbiasa dengan ekosistem Go yang tangguh dalam membangun layanan jaringan berkinerja tinggi.

Namun, tidak semua skenario cocok dengan pendekatan ini. Ada kalanya jalan lain harus ditempuh.

6. Kapan Wajib Menggunakan Alternatif Lain (Misalnya WebSocket/Node.js)

Anda harus meninggalkan SSE dan beralih ke WebSocket atau stack alternatif ketika:

• Komunikasi Dua Arah Aktif (Bidirectional): Aplikasi memerlukan klien mengirim data dengan frekuensi tinggi secara bersamaan melalui koneksi yang sama, seperti game multiplayer real-time atau aplikasi kolaborasi dokumen interaktif (Google Docs style).
• Dukungan Legacy Browser Ekstrem: Meskipun SSE didukung oleh hampir semua browser modern, jika target audiens Anda masih menggunakan perangkat lama di lingkungan korporat tertutup yang memblokir koneksi HTTP Keep-Alive lama, WebSocket dengan fallback polyfill mungkin diperlukan.
• Keterbatasan Tim Pengembang: Jika seluruh tim engineering Anda adalah spesialis JavaScript/TypeScript penuh dan tidak memiliki waktu atau sumber daya untuk mempelajari concurrency model di Golang, kecepatan pengembangan (time-to-market) sering kali mengalahkan optimalisasi performa mentah.

Keputusan akhir ini merangkum seluruh pengalaman dan pertempuran arsitektur yang telah kita lalui di lapangan.

7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Membangun Real-Time LLM Streaming Gateway bukanlah ajang mencari teknologi yang paling populer di media sosial, melainkan seni mencocokkan karakteristik beban kerja dengan kemampuan intrinsik alat yang digunakan. Golang dan Server-Sent Events (SSE) terbukti menjadi kombinasi juara untuk menangani lonjakan token dari Large Language Model dengan latensi minimal, konsumsi RAM yang sangat hemat, serta kemudahan integrasi dengan infrastruktur web yang sudah ada.

Jangan terjebak dalam jebakan 'WebSocket untuk Segala Hal'. Jika produk Anda adalah chatbot AI, assistant coding, atau sistem analisis teks real-time, SSE dengan backend Golang adalah arsitektur yang akan membuat tidur Anda nyenyak di malam hari tanpa kejutan grafik memori meledak di Grafana. Rancang arsitekturnya dengan benar, uji beban sebelum rilis ke production, dan biarkan data berbicara.