Wawancara Backend: Kapan Anda Harus Memilih REST atau gRPC?

Prompt dan Konteks yang Berlaku

Sebuah platform memiliki tiga batasan API. Browser, aplikasi seluler, dan mitra eksternal mengonsumsi yang pertama, sehingga harus mudah diintegrasikan, didebug, dan dikembangkan secara independen. Yang kedua adalah lalu lintas antar-layanan (service-to-service) di lingkungan pusat data yang terkontrol. Beban puncaknya mencapai 20.000 panggilan per detik dan membutuhkan panggilan request-response biasa serta server stream. Yang ketiga menerima callback webhook dari sistem eksternal.

Angka 20.000 panggilan per detik adalah asumsi wawancara, bukan ambang batas performa universal. Pilihlah HTTP bergaya REST dengan JSON, gRPC native, atau kombinasi yang beralasan untuk setiap batasan, lalu jelaskan migrasi dan validasinya. REST adalah gaya arsitektur dan tidak terikat pada JSON atau HTTP/1.1. "REST/HTTP+JSON" hanyalah penetapan implementasi umum yang dibandingkan dalam prompt ini. gRPC bukanlah tombol sakelar yang secara otomatis membuat sebuah operasi menjadi cepat, idempoten, atau andal.

Ini adalah pertanyaan backend karena intinya adalah antarmuka layanan, semantik protokol, kontrak klien, dan tata kelola produksi. Pertanyaan ini tidak meminta keseluruhan sistem bisnis, dan tabel hafalan "gRPC lebih cepat; REST lebih kompatibel" tidaklah cukup.

Hal yang Dievaluasi Pewawancara

Sinyal pertama adalah apakah kandidat memulai dari konsumen dan batasan jaringan. Browser publik dan ekosistem mitra menghargai perkakas HTTP yang ada di mana-mana, payload yang mudah dibaca, semantik caching, dan biaya integrasi yang rendah. Pemanggil internal yang terkontrol dapat lebih mudah menstandarisasi file .proto, kode yang dihasilkan (generated code), proksi, dan load balancing. Protokol dapat mengikuti batasan; sebuah platform tidak harus mengekspos hanya satu gaya antarmuka.

Sinyal kedua adalah memisahkan abstraksi dari implementasi. REST menggunakan resource, metode HTTP, kode status, dan semantik caching, serta dapat berjalan di atas HTTP/2 atau HTTP/3. gRPC berpusat pada layanan dan metode, menggunakan Protocol Buffers sebagai definisi antarmuka dan pesan default-nya, serta menyediakan metode unary, client-streaming, server-streaming, dan bidirectional-streaming. "REST hanya menggunakan HTTP/1.1" dan "REST tidak dapat melakukan streaming" keduanya merupakan jalan pintas yang keliru.

Sinyal ketiga adalah melengkapi kontrak dan model kegagalan. OpenAPI dapat memberikan kontrak yang dapat dibaca mesin dan pembuatan kode untuk API HTTP. Kompatibilitas biner Protobuf tidak menjamin kompatibilitas aplikasi. Pilihan mana pun tetap memerlukan deadline, pembatalan, idempoten, aturan kesalahan yang dapat dicoba ulang (retryable-error), autentikasi, otorisasi, evolusi versi, dan identitas permintaan yang dapat diobservasi.

Terakhir, kandidat yang kuat meminta bukti. Mereka melakukan benchmark pada payload yang representatif, konkurensi, kompresi, perilaku koneksi, dan kegagalan, lalu melakukan rilis canary pada hasilnya sambil mengukur tail latency dan error. Migrasi platform yang hanya didasari oleh "biner lebih cepat" bukanlah rekayasa yang dapat direproduksi.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Siapa yang mengontrol klien dan pembaruan (upgrade)? Layanan di dalam satu organisasi dapat mengoordinasikan rilis klien yang dihasilkan (generated-client). Mitra yang tidak dapat dipaksa untuk melakukan pembaruan membutuhkan batasan stabil yang mudah dikonsumsi secara independen.
• Apakah interaksinya bersifat unary, streaming, atau notifikasi asinkron? CRUD biasa tidak secara otomatis diuntungkan oleh gRPC. Stream yang berurutan melalui koneksi berumur panjang mungkin cocok untuk gRPC native. Webhook pihak ketiga diinisiasi oleh pihak lain dan biasanya harus mengikuti kontrak HTTP yang dipublikasikan pihak tersebut.
• Haruskah browser memanggil layanan secara langsung? Browser tidak dapat secara langsung menyediakan semua kontrol HTTP/2 yang diperlukan oleh gRPC native. gRPC-Web, transcoding JSON, atau BFF menambahkan lapisan yang mengubah debugging, kemampuan streaming, dan operasional.
• Apa masalah performa yang sebenarnya? Mengubah serialisasi tidak akan menghilangkan bottleneck basis data, fan-out downstream, atau kueri tanpa batas. Tanyakan ukuran payload, QPS, konkurensi, p95/p99, CPU, dan anggaran jaringan.
• Apa yang didukung oleh gateway dan stack observabilitas saat ini? Dukungan proksi untuk status gRPC, stream, health check, dan korelasi trace end-to-end secara langsung mengubah risiko peluncuran (rollout).
• Bagaimana antarmuka harus berevolusi? API publik membutuhkan kebijakan kompatibilitas. Protobuf internal membutuhkan aturan nomor field (field-number) dan versi campuran (mixed-version). Tanpa pengujian lintas-versi, kontrak bertipe kuat (strongly typed) masih dapat gagal selama deployment bergulir (rolling deployment).

Kerangka Jawaban 30 Detik

"Saya akan memilih berdasarkan batasan konsumen, bukan membuat satu pilihan untuk seluruh platform. API browser, seluler, dan mitra dimulai sebagai HTTP bergaya REST dengan JSON, yang diatur oleh OpenAPI, semantik HTTP, dan kebijakan kompatibilitas. Webhook pihak ketiga juga mengikuti kontrak HTTP publiknya. Untuk jalur internal terkontrol pada 20.000 panggilan per detik, saya akan memilih gRPC native jika benchmark representatif menunjukkan biaya serialisasi atau koneksi berpengaruh dan server stream merupakan kebutuhan nyata. Klien yang dihasilkan tidak menghilangkan kebutuhan untuk menetapkan deadline, menyebarkan pembatalan, mencoba ulang hanya operasi yang aman, dan menjaga kompatibilitas field. Di bagian edge, transcoding JSON atau gateway tipis dapat berbagi satu implementasi domain. Sebelum peluncuran, saya akan membandingkan p99 end-to-end, CPU, byte, dan pemulihan kegagalan dengan payload nyata, lalu memigrasikannya berdasarkan pemanggil. Protokol tidak menggantikan autentikasi, idempoten, atau observabilitas."

Pembahasan Mendalam Langkah-demi-Langkah

Langkah 1: Tentukan setiap batasan secara terpisah

Gunakan HTTP bergaya REST dengan JSON untuk batasan publik. URI resource, metode, kode status, conditional request, dan caching dipahami secara luas oleh browser, CDN, command-line tool, dan mitra. OpenAPI dapat menjadi sumber kontrak untuk dokumentasi dan SDK yang dihasilkan, sehingga menggambarkan REST sebagai "tanpa tipe dan ditulis manual" tidaklah adil. Biayanya adalah tim harus secara aktif mengatur model error, paginasi, open enum, dan pergeseran spesifikasi (specification drift).

Pilihlah gRPC untuk batasan internal hanya setelah dua syarat terpenuhi: pemanggil dan server dapat menstandarisasi kode yang dihasilkan dan infrastruktur runtime, serta benchmark representatif menunjukkan manfaat yang cukup untuk menutupi kompleksitas proksi, debugging, dan versi campuran. Prompt ini juga memiliki kebutuhan server-streaming yang nyata. Metode streaming gRPC beserta metadata, status, dan deadline per panggilan membentuk model yang koheren untuk itu. Angka 20.000 QPS saja tidak menjadi penentu keputusan.

Gunakan webhook HTTP untuk callback pihak ketiga. Pengirim eksternal mengontrol protokol, dan penerima publik membutuhkan TLS, verifikasi tanda tangan, pengakuan (acknowledgment) cepat, dan pemrosesan asinkron. Mengganti penerima dengan gRPC tidak membuat mitra yang mengirimkan permintaan HTTP POST menjadi bisa memanggilnya. Jika jalur pemrosesan internal menggunakan gRPC, adaptor webhook akan memverifikasi dan mempertahankan event sebelum memanggil jalur tersebut.

Langkah 2: Tulis kontrak yang dapat dieksekusi

Antarmuka pembacaan publik menggunakan resource dan semantik HTTP:

GET /v1/orders/ord_123
If-None-Match: "order-v7"

200 OK
ETag: "order-v7"
Content-Type: application/json

Antarmuka internal mendefinisikan aksi dan pesan:

service OrderService {
  rpc GetOrder(GetOrderRequest) returns (Order);
  rpc WatchOrder(WatchOrderRequest) returns (stream OrderEvent);
}

message GetOrderRequest {
  string order_id = 1;
}

Kedua kontrak memerlukan autentikasi, otorisasi, penanganan error, paginasi atau aturan penghentian stream, batas ukuran, dan field audit. Nama metode gRPC dapat menyembunyikan biaya jaringan, tetapi pemanggil harus tetap memperlakukannya sebagai operasi jarak jauh dengan latensi, batas waktu (timeout), dan kegagalan parsial. REST POST juga tidak otomatis idempoten; operasi pembuatan (create) membutuhkan kunci idempoten yang stabil atau batasan keunikan bisnis.

Langkah 3: Rancang semantik kegagalan

Secara default, klien gRPC mungkin tidak memiliki deadline, jadi tetapkan satu dari anggaran end-to-end. Berakhirnya deadline membuat pemanggil berhenti menunggu, tetapi aplikasi server tetap bertanggung jawab untuk menghentikan pekerjaan yang telah dipicunya. Propagasi deadline dan pembatalan juga harus diverifikasi untuk bahasa dan framework yang dipilih. Klien HTTP juga membutuhkan anggaran koneksi, respons, dan total; nilai default soket bukanlah SLO bisnis.

Keputusan percobaan ulang (retry) berasal dari semantik bisnis. HTTP GET, HEAD, PUT, dan DELETE memiliki sifat aman atau idempoten dalam spesifikasi, tetapi implementasi harus menghormati semantik metode tersebut. POST aman untuk dicoba ulang hanya jika kunci idempoten atau mekanisme yang setara membuat hasilnya aman. Nama metode gRPC tidak mendapatkan idempoten otomatis; kontrak harus mengidentifikasi status dan operasi yang dapat dicoba ulang. Kedua pendekatan memerlukan batas percobaan, pemeriksaan sisa deadline, dan perlindungan terhadap penumpukan percobaan ulang di gateway, SDK, dan aplikasi.

RPC streaming menambahkan penanganan slow-consumer, backpressure, batas per pesan, posisi pelanjutan (resume position), dan event duplikat. Jika konsumen harus melanjutkan dari sebuah kursor, event memerlukan ID atau nomor urut yang stabil. Membuka kembali stream saja tidak dapat membuktikan bahwa tidak ada celah data yang hilang atau duplikat.

Langkah 4: Buat kontrak bertahan dalam evolusi bertahap

Kompatibilitas REST/JSON mencakup struktur dan semantik. Menambahkan field respons hanya aman jika klien menoleransi field yang tidak dikenal. Mengubah paginasi default, pengurutan, atau arti enum dapat membuat JSON tetap dapat di-parse tetapi merusak aplikasi. Saring rilis dengan perbandingan (diff) OpenAPI, SDK publik terakhir, replay permintaan yang direkam, dan assertion end-to-end.

Menambahkan field Protobuf biasanya aman secara biner (wire-safe) karena pembaca lama mengabaikan field yang tidak dikenal, tetapi kode aplikasi masih dapat rusak karena enum atau nilai default baru. Jangan pernah mengubah nomor field yang sudah ada. Pesan (reserve) nomor dan nama field yang dihapus agar keduanya tidak digunakan kembali. Selama rilis bergulir, uji klien lama dengan server baru dan klien baru dengan server lama; pengujian versi yang sama saja tidak cukup.

Ketika klien edge dan internal membutuhkan kemampuan yang sama, bagikan logika domain dan sumber kontrak yang eksplisit, lalu ekspos HTTP melalui transcoding JSON atau adaptor tipis jika sesuai. Adaptor harus memetakan status HTTP ke status gRPC, header ke metadata, nama field, autentikasi, dan batasan streaming. Dua implementasi bisnis yang disinkronkan secara manual akan mengalami pergeseran (drift).

Langkah 5: Biarkan bukti berbentuk produksi menentukan migrasi

Gunakan distribusi payload dan campuran metode yang nyata, bukan microbenchmark yang hanya melakukan serialisasi satu objek kecil. Terhadap logika domain yang sama, ukur throughput end-to-end, p50/p95/p99, CPU klien dan server, byte yang ditransfer, koneksi, dan memori. Cakup panggilan unary, pesan kecil dan besar, kompresi, server stream, slow consumer, dan lalu lintas lintas-zona. Pertahankan beban kerja basis data dan downstream tetap identik sehingga efek protokol dapat diisolasi.

Jalankan satu metode internal berisiko rendah dalam mode dual-stack dan lakukan canary berdasarkan pemanggil. Bandingkan hasil bisnis, klasifikasi error, kejadian deadline exceeded, pekerjaan yang berlanjut setelah pembatalan, amplifikasi percobaan ulang, dan kelengkapan trace. Lakukan ekspansi hanya setelah memenuhi ambang batas manfaat dan keandalan yang telah tertulis. Mempertahankan API HTTP ketika peningkatannya tidak signifikan adalah hasil yang valid.

Contoh Jawaban Berkualitas Tinggi

"Saya tidak akan melabeli seluruh platform sebagai REST atau gRPC. Saya akan mulai dari siapa yang memanggil setiap batasan, siapa yang mengontrol pembaruan, dan bagaimana pola komunikasinya.

Untuk browser, aplikasi seluler, dan mitra, saya akan menggunakan HTTP bergaya REST dengan JSON. Ini bekerja dengan ekosistem HTTP yang luas, sementara OpenAPI menyediakan kontrak yang dapat dibaca mesin, pembuatan SDK, dan pemeriksaan kompatibilitas. Webhook pihak ketiga tetap berupa HTTP POST karena protokol pengirim merupakan kendala eksternal. Ingress memverifikasi tanda tangan, melakukan deduplikasi berdasarkan ID event, menyimpan event, dan memprosesnya secara asinkron.

Batasan internal memiliki 20.000 panggilan per detik dan server stream. Saya akan melakukan benchmark terhadap payload berbentuk produksi. Jika semua pemanggil dapat menggunakan klien yang dihasilkan, proksi, load balancer, dan pemantauan memahami gRPC, serta p99, CPU, atau bandwidth meningkat cukup signifikan untuk memenuhi ambang batas tertulis, saya akan menggunakan gRPC di sana. Metode unary dan streaming berada di .proto, tetapi setiap panggilan tetap mendapatkan deadline, pembatalan menghentikan pekerjaan yang dipicu, dan hanya operasi yang aman secara kontrak yang dicoba ulang.

Untuk evolusi, API HTTP menggunakan perbandingan OpenAPI, SDK lama, dan replay semantik untuk menangkap kerusakan paginasi atau enum. Nomor field Protobuf tidak pernah diubah, field yang dihapus di-reserve, dan pasangan klien-server lama/baru diuji silang. Jika antarmuka publik dan internal berbagi suatu kemampuan, satu implementasi domain melayani adaptor HTTP dan layanan gRPC, atau menggunakan transcoding JSON setelah pemetaannya diverifikasi.

Saya akan melakukan canary berdasarkan pemanggil dan mengamati p99 end-to-end, CPU, byte, pemetaan status, amplifikasi percobaan ulang, dan kelengkapan trace. Jika peningkatan hanya ada pada microbenchmark sementara bottleneck produksi tetap berada pada basis data, saya tidak akan memperluas migrasi hanya demi keseragaman protokol."

Kesalahan Umum

• Menyamakan REST dengan HTTP/1.1 → Semantik HTTP dan versi transport dicampuradukkan → Nyatakan bahwa REST API dapat berjalan di atas HTTP/2 atau HTTP/3.
• Mengklaim gRPC selalu lebih cepat → Penyimpanan, logika bisnis, atau proksi mungkin lebih mendominasi → Lakukan benchmark pada pekerjaan domain yang identik dengan payload representatif dan tail latency.
• Mengatakan REST tidak memiliki kontrak yang kuat → Ini mengabaikan deskripsi, pembuatan kode, dan pengujian OpenAPI → Bandingkan alur kerja kontrak yang sebenarnya, bukan spesifikasi yang terabaikan dengan spesifikasi yang terawat.
• Memanggil gRPC native langsung dari browser → Browser tidak memiliki kontrol gRPC native yang diperlukan → Gunakan gRPC-Web, transcoding JSON, atau BFF dan perhitungkan batasannya.
• Melewatkan deadline gRPC → Klien dapat menunggu tanpa batas waktu dan menghabiskan sumber daya → Turunkan deadline dari anggaran end-to-end dan verifikasi pembatalan.
• Memperlakukan kompatibilitas biner Protobuf sebagai kompatibilitas aplikasi → Enum, nilai default, dan arti baru masih dapat merusak kode → Lakukan pengujian silang antar versi dan reserve nomor field.
• Mengaktifkan percobaan ulang di setiap lapisan → Kegagalan mengamplifikasi lalu lintas dan operasi tulis dapat berulang → Pusatkan percobaan ulang dan batasi operasi yang aman, sisa waktu, serta jumlah percobaan.
• Mempertahankan satu protokol hanya demi keseragaman → Biaya integrasi publik atau kebutuhan streaming internal dikorbankan → Gunakan edge HTTP dan batasan internal gRPC yang eksplisit jika beralasan.

Pertanyaan Lanjutan dan Jawabannya

Lanjutan 1: Haruskah API internal dengan hanya 500 QPS tetap menggunakan gRPC?

QPS saja tidak dapat menentukan. Organisasi dengan platform gRPC yang matang, kontrak yang dihasilkan lintas-bahasa, dan kebutuhan streaming mungkin masih mendapatkan manfaat pada 500 QPS. Tim dengan satu layanan CRUD sederhana, perkakas HTTP yang matang, dan ruang performa yang luas kemungkinan memiliki biaya operasional yang lebih rendah dengan REST/HTTP+JSON. Tuliskan metrik target terlebih dahulu; jangan bermigrasi jika keuntungannya tidak dapat dibuktikan.

Lanjutan 2: Aplikasi seluler publik dapat menggunakan klien gRPC yang dihasilkan. Bisakah gRPC menjadi API publik?

Ini bisa menjadi kandidat untuk klien seluler yang terkontrol, tetapi ujilah proksi, jaringan perusahaan, perkakas debugging, penanganan sertifikat, kompatibilitas versi, dan ritme rilis. Mitra dan browser mungkin masih memerlukan API HTTP, jadi gRPC publik tidak secara otomatis menghilangkan biaya protokol ganda (dual-protocol). Putuskan berdasarkan kelompok pemanggil alih-alih memperlakukan "Internet publik" sebagai satu klien.

Lanjutan 3: Bagaimana satu .proto dapat mengekspos API JSON juga?

Anotasikan metode dengan pemetaan HTTP dan gunakan transcoding JSON atau gateway. Sebelum peluncuran, verifikasi nama field, perilaku null dan default, pemetaan status HTTP dan gRPC, metadata dan header, autentikasi, caching, dan batasan streaming. Sumber kontrak .proto mengurangi duplikasi, tetapi semantik adaptor tetap memerlukan pengujian.

Lanjutan 4: Bagaimana stream gRPC dapat dilanjutkan kembali tanpa kehilangan event?

Protokol ini menyediakan streaming dan pengurutan dalam satu RPC, bukan langganan bisnis yang tahan lama (durable). Berikan nomor urut yang stabil pada event, simpan log yang dapat diputar ulang (replayable), dan minta klien mempertahankan atau mengirim kursor yang telah dikonsumsi saat menyambung kembali. Tentukan retensi, penanganan kursor kedaluwarsa, dan deduplikasi. Jika persyaratan tersebut mendominasi, bandingkan dengan antrean atau log pesan daripada memaksakan RPC menjadi seperti itu.

Lanjutan 5: Benchmark menunjukkan p99 gRPC lebih baik, tetapi produksi tidak. Apa yang Anda periksa?

Urai latensi menjadi antrean klien, DNS dan pekerjaan koneksi, proksi, serialisasi, logika aplikasi, basis data, dan panggilan downstream. Periksa apakah payload produksi, kompresi, penggunaan kembali koneksi, TLS, perutean lintas-zona, dan percobaan ulang tersembunyi sesuai dengan benchmark. Jika protokol hanya merupakan sebagian kecil dari total latensi, optimalkan komponen yang dominan alih-alih memperluas migrasi.