RFC #

RFC (Request for Comments) dalam konteks software engineering adalah dokumen formal yang digunakan untuk mengusulkan, mendiskusikan, dan mendokumentasikan perubahan teknis sebelum perubahan tersebut benar-benar diimplementasikan.

RFC bukan sekadar dokumentasi akhir, melainkan alat komunikasi dan pengambilan keputusan teknis.

RFC bisa mencakup:

Perubahan arsitektur
Penambahan fitur besar
Perubahan API
Perubahan database schema
Perubahan behavior sistem yang berdampak luas

Awalnya, istilah RFC populer dari dunia internet standards (IETF), namun di dunia engineering modern (Google, Meta, Netflix, Stripe, dll), RFC diadaptasi sebagai engineering decision record yang terstruktur.

Tujuan RFC #

RFC dibuat bukan untuk birokrasi, tapi untuk menghindari masalah mahal di masa depan.

Tujuan utamanya:

1. Menyatukan Pemahaman #

Semua stakeholder (engineer, reviewer, product, ops) membaca dokumen yang sama, dengan asumsi yang sama.

2. Mencegah Keputusan Sepihak #

RFC memaksa ide besar untuk dibuka ke publik internal, bukan langsung di-commit ke repository.

3. Mengurangi Rework #

Lebih murah membuang ide di fase dokumen daripada membuang kode setelah production.

4. Dokumentasi Keputusan Teknis #

RFC menjawab pertanyaan klasik:

“Kenapa sistem ini dibangun seperti ini?”

Bukan apa yang dibangun, tapi mengapa.

5. Sarana Diskusi Asinkron #

Tim tidak perlu selalu meeting panjang. Komentar bisa dilakukan async, lebih scalable.

Mengapa RFC Itu Penting? #

Perubahan Teknis Selalu Punya Dampak #

Perubahan kecil di satu service bisa berdampak ke:

Performance
Scalability
Database load
Cost
Security

RFC memaksa engineer berpikir end-to-end sebelum coding.

Menghindari “Hero Engineering” #

Tanpa RFC:

Engineer senior langsung implement
Review terjadi setelah kode jadi
Diskusi terlambat

Dengan RFC:

Ide diuji dulu
Semua level engineer bisa berkontribusi
Keputusan lebih objektif

Skala Tim & Organisasi #

Semakin besar tim:

Knowledge tidak bisa hanya di kepala
Keputusan harus traceable

RFC menjadi single source of truth.

Mengurangi Risiko Production Incident #

Banyak incident berasal dari:

Assumption yang salah
Edge case yang tidak terpikirkan
Dampak yang tidak dianalisis

RFC yang baik memaksa engineer menuliskan:

Failure scenario
Rollback plan
Migration strategy

Kapan Sebaiknya Membuat RFC? #

Gunakan RFC jika perubahan:

Berdampak ke banyak service
Mengubah kontrak API
Mengubah data model
Berdampak ke performance / cost
Sulit di-rollback
Akan dipakai jangka panjang

Tidak semua PR butuh RFC.

Rule of thumb:

Jika perubahan sulit dijelaskan dalam 5 menit, kemungkinan besar butuh RFC.

Struktur RFC yang Baik (Best Practice) #

RFC yang baik itu:

Jelas
Ringkas
Fokus ke decision
Bukan proposal satu arah

Di bawah ini adalah template RFC yang umum dipakai di banyak organisasi besar.

Contoh Template RFC (Best Practice) #

Judul RFC #

Judul harus singkat dan deskriptif.

Contoh: RFC: Asynchronous Processing untuk Upload File Besar

Status #

Menunjukkan lifecycle RFC.

Draft
In Review
Accepted
Rejected
Implemented

Author & Reviewer #

Author: Nama / Tim
Reviewer: Nama / Tim terkait

Latar Belakang (Background) #

Jelaskan:

Kondisi saat ini
Masalah yang terjadi
Data atau fakta pendukung

Contoh:

Saat ini proses upload file Excel diproses secara synchronous. Rata-rata waktu pemrosesan 3–5 menit, menyebabkan timeout dan poor user experience.

Problem Statement #

Tuliskan masalah secara eksplisit dan terukur.

Apa yang salah?
Dampaknya apa?
Siapa yang terdampak?

Tujuan & Non-Tujuan #

Tujuan #

Apa yang ingin dicapai RFC ini

Non-Tujuan #

Apa yang tidak ingin diselesaikan

Ini penting untuk mencegah scope creep.

Proposal / Solusi yang Diusulkan #

Jelaskan solusi secara detail:

High-level design
Flow diagram (jika perlu)
Komponen yang terlibat

Fokus ke bagaimana sistem bekerja, bukan detail implementasi kode.

Alternatif yang Dipertimbangkan #

Tuliskan:

Alternatif lain
Kenapa tidak dipilih

Ini menunjukkan keputusan dibuat secara sadar, bukan kebetulan.

Dampak & Risiko #

Bahas secara jujur:

Performance impact
Database load
Operational complexity
Security risk

Termasuk failure scenario.

Migration & Rollback Plan #

Bagaimana migrasi dari sistem lama
Apakah bisa gradual
Bagaimana rollback jika gagal

Bagian ini sering dilupakan, padahal sangat krusial.

Open Questions #

Daftar pertanyaan yang:

Belum terjawab
Butuh masukan reviewer

RFC tidak harus sempurna di awal.

Appendix (Opsional) #

Detail teknis tambahan
Benchmark
Referensi

Best Practice Menulis RFC #

1. RFC Bukan Tempat Pamer Skill #

Tujuannya clarity, bukan kompleksitas.

2. Fokus ke “Why” daripada “How” #

Detail kode bisa berubah, alasan keputusan jarang berubah.

3. Terima Kritik Sejak Dini #

RFC yang bagus biasanya berubah beberapa kali sebelum accepted.

4. Jangan Terlalu Panjang #

Idealnya:

2–6 halaman
Bisa dibaca dalam 15–30 menit

5. Update Status dan Hasil Akhir #

Setelah implementasi:

Tandai RFC sebagai Implemented
Tambahkan catatan hasil

RFC adalah dokumen hidup.

Penutup #

RFC adalah salah satu tools paling underrated dalam software engineering.

Bukan soal formalitas, tapi soal:

Mengurangi risiko
Meningkatkan kualitas keputusan
Membuat tim lebih scalable

Semakin besar dampak perubahan, semakin besar nilai sebuah RFC yang ditulis dengan baik.

Good engineers write code. Great engineers write decisions.