Arsitektur Direct Upload Cloudflare R2 dengan S3 Presigned URL, Go, dan Next.js pada Sistem SaaS Multi-Tenant

1. Mengapa Mengunggah File Melalui Server Backend Pasti Melumpuhkan Sistem?

Pernahkah kamu mengalami mimpi buruk di mana server aplikasi backend-mu mendadak mati suri karena kehabisan memori (Linux OOM Killerℹ) tepat saat beberapa pengguna mengunggah dokumen PDF atau video berukuran puluhan megabyte secara bersamaan? Atau pernahkah kamu terperangah melihat tagihan cloud membengkak ratusan dolar hanya gara-gara biaya transfer data keluar (egressℹ bandwidth)?

Pengalaman menegangkan itulah yang pernah saya dan tim hadapi ketika pertama kali merilis platform SaaS manajemen dokumen kolaboratif. Di awal pengembangan, kami menggunakan pendekatan paling umum:

Di atas kertas, kode controller backend tampak sederhana dan berjalan normal saat diuji dengan file 2 MB di laptop pengembang. Namun, begitu platform dilempar ke pengguna enterprise dengan file-file berukuran 50 MB hingga 500 MB, arsitektur proxy tersebut langsung runtuh:

• Server Crash Berulang (Out-Of-Memory Panic): Ketika puluhan pengguna mengunggah file besar di jaringan kantor yang padat, thread pool backend tertahan menampung buffer binary di RAM. Memori server melonjak dari 150 MB menjadi 7,8 GB dalam hitungan detik, memicu OOM Killerℹ dan merestart podℹ backend berulang kali (crash loopℹ).
• Koneksi Klien Lambat Menguras Socket (Slow-Client Starvation): Pengguna di jaringan ponsel yang lambat menahan soket HTTP server selama bermenit-menit hanya untuk menyelesaikan upload satu file. Akibatnya, pengguna lain yang ingin melakukan login atau input data sederhana tercekik dengan error 502 Bad Gateway.
• Bencana Tagihan Egressℹ Ganda: Server backend kami harus membayar dua kali biaya jaringan: ingressℹ saat file masuk ke server, dan egressℹ saat server menyalurkannya kembali ke cloud storage.
• Kebocoran Kuotaℹ Storage Tenant (Double-Spend): Karena kuota baru dipotong setelah file selesai diunggah ke server, pengguna nakal dapat membuka 5 tab secara bersamaan untuk mengunggah file besar, menimbun hingga 1,8 TB data di atas paket langganan yang seharusnya dibatasi 250 GB!

Dari rangkaian masalah tersebut, kami menarik satu prinsip arsitektural mutlak: data binary berukuran besar tidak boleh pernah menyentuh proses memori server backend aplikasi. Server backend bertindak sebagai penjaga gerbang (Identity & Quota Gatekeeper), sedangkan aliran binary dialirkan langsung (direct streaming) dari browser ke object storage melalui S3 Presigned URLℹ.

2. Peta Topologi dan Matriks Komparasi Paradigma Upload

Sebelum membedah implementasi kode, mari kita bandingkan perbedaan mendasar antara pola lama (Server Multipart Proxy) dan pola modern (Direct-to-Storage Presigned URLℹ):

3. Tiga Masalah Nyata di Balik Kerusakan Sistem Upload Tradisional

Masalah 1: Serangan Concurrent Burst yang Membocorkan Kuota (Double-Spend Storage)

Jika sistem hanya memeriksa kuota di awal tanpa mekanisme reservasi atomikℹ:

• Pengguna paket Free (kuota 500 MB) yang sisa kuotanya tinggal 100 MB membuka 5 tab browser sekaligus.
• Di masing-masing tab, pengguna mengunggah file berukuran 90 MB.
• Jika pemeriksaan kuota hanya berupa if (used + 90MB > 500MB), kelima request akan sama-sama lolos karena saat dicek, sisa kuota masih 100 MB!
• Akibatnya, tenant berhasil menyimpan 450 MB data baru dan kuota bocor sebesar 350 MB.

Solusi 1: Atomic Two-Phase Quota Reservation & Reconciliation

Kami menerapkan model Three-Way Handshake:

1. 1Fase 1 (Soft Reservation): Mengunci baris kuota di database menggunakan transaksi atomikℹ SELECT current_storage_bytes, reserved_storage_bytes FROM tenant_subscriptions FOR UPDATE. Tambahkan ukuran file ke reserved_storage_bytes. Jika melebihi batas, tolak dengan HTTP 403 Forbidden.
2. 2Fase 2 (Direct Upload): Klien mengunggah langsung ke R2.
3. 3Fase 3 (Hard Commit): Klien memanggil endpoint konfirmasi. Backend memeriksa ukuran riil via HeadObject, memindahkan byte dari reserved ke current, dan menandai status tiket selesai. Cron worker membersihkan reservasi yang menggantung jika klien membatalkan upload.

Masalah 2: Pemalsuan Ukuran Binary (Content-Length Spoofing)

Klien nakal dapat meminta presigned URLℹ dengan melaporkan ukuran file 1 MB, namun saat menembak URL R2, klien mengirim file berukuran 2 GB untuk membobol kuota.

Solusi 2: Kriptografi Presign URL dengan Penguncian Header Mutlak

Saat memanggil fungsi presign di Go AWS SDK v2, kita mengunci header ContentLength dan ContentType ke dalam tanda tangan kriptografis URL. Cloudflare R2 secara otomatis menolak dengan status HTTP 403 jika payload yang dikirimkan klien tidak sesuai persis dengan ukuran byte yang ditandatangani.

Masalah 3: Tagihan Egress Membengkak Gila-Gilaan pada Storage Konvensional

Pada cloud storage konvensional seperti AWS S3, biaya transfer data keluar (data egressℹ fee) dipatok sekitar $0,09 per gigabyte. Untuk aplikasi SaaS dengan ribuan pengguna yang mengunduh dan membaca dokumen setiap hari, tagihan bandwidth keluar sering kali jauh lebih mahal daripada biaya sewa penyimpanan itu sendiri.

Solusi 3: Pemanfaatan Cloudflare R2 Bebas Biaya Egress

Cloudflare R2 menyediakan API yang 100% kompatibel dengan protokol AWS S3, namun dengan kebijakan revolusioner: $0 Data Egressℹ Fee. Hal ini memungkinkan platform kami menghemat ratusan hingga ribuan dolar per bulan untuk transfer data dokumen.

4. Kasus Nyata di Medan Produksi: Insiden OOM Server dan Kebocoran Kuota 1.8 TB

Pada kuartal ketiga implementasi SaaS manajemen dokumen kami, tim mengalami salah satu insiden paling genting:

Setelah insiden tersebut, tim kami membongkar total jalur upload proxy multipart dan menggantinya dengan model Direct Cloudflare R2 Presigned PUT dengan reservasi atomikℹ. Sejak arsitektur baru diterapkan, beban RAM backend tetap datar di bawah 32 MB meskipun ratusan klien mengunggah file gigabyte secara serentak.

5. Implementasi Kode Go & Next.js Skala Produksi

Berikut adalah arsitektur kode produksi yang memisahkan tanggung jawab secara bersih antara gatekeeper Go dan uploader Next.js:

A. Konfigurasi Client Cloudflare R2 di Go (AWS SDK v2)

B. Handler Reservasi Kuota & Pembuat Presigned URL (Go)

C. Handler Konfirmasi & Validasi HeadObject (Go)

D. Frontend Client Uploader di Next.js (TypeScript)

Komponen React di browser yang menangani streaming langsung ke R2 menggunakan XMLHttpRequest untuk pelacakan persentase progres yang akurat:

6. Hasil Riil di Produksi: Metrik Sebelum vs Sesudah

Kami menguji arsitektur ini dengan melakukan load test 500 pengguna aktif yang mengunggah file media 50 MB secara simultan:

7. 5 Kaidah Emas Keamanan & Rekonsiliasi Upload di Produksi

1. 1Konfigurasi CORS Terbatas: Pastikan bucket R2 hanya menerima method PUT dan HEAD dari origin domain aplikasi SaaS resmi kamu (https://app.yourdomain.com). Jangan pernah menggunakan wildcard *.
2. 2Kunci Header Content-Type dan Content-Length pada Signature: Saat memanggil PresignPutObject, sertakan ukuran byte dan tipe konten eksplisit agar pengguna tidak bisa menyelundupkan file raksasa dengan izin file kecil.
3. 3Masa Berlaku URL Singkat: Tetapkan batas kedaluwarsa presigned URLℹ maksimal 15 menit. URL ini harus diperlakukan sebagai token transaksi sekali pakai.
4. 4Validasi File Magic Bytes di Background Worker: Gunakan worker asinkron untuk membaca 512 byte pertama (magic numbers) file di storage guna memverifikasi integritas tipe data riil sebelum aset dipublikasikan ke publik.
5. 5Jalankan Reconciliationℹ Cron Job: Pasang cron job berkala setiap 30 menit untuk mengembalikan nilai reserved_storage_bytes yang tiketnya kedaluwarsa tanpa pernah dikonfirmasi, memastikan kuota tenant tidak menggantung akibat masalah jaringan pengguna.