Wawancara Backend: Bagaimana Anda mendesain kontrak HTTP 413 Content Too Large?

Perintah dan cakupan

Sebuah unggahan video melewati CDN, API gateway, layanan aplikasi, dan penyimpanan objek, masing-masing dengan ukuran yang diterima berbeda. Desain respons 413 Content Too Large, penemuan batasan (limit discovery), unggahan yang dapat dilanjutkan (resumable upload), Retry-After, isi pesan kesalahan (error body), dan pemantauan.

Ini adalah pertanyaan reliabilitas API backend. Jumlah lapisan dan ukuran video adalah asumsi, bukan klaim frekuensi.

Apa yang sedang diuji oleh pewawancara

• Apakah Anda memisahkan batas permanen, kapasitas sementara, dan kegagalan validasi bodi.
• Apakah Anda menjelaskan hubungan antara 413 dan Retry-After secara tepat.
• Apakah Anda mendesain kemampuan melanjutkan (resumability) alih-alih mencoba kembali seluruh bodi.
• Apakah Anda menangani batasan proksi, idempotensi, dan kebocoran informasi.

Pertanyaan klarifikasi yang perlu diajukan

1. Lapisan mana yang mengeluarkan 413, dan apakah cakupan serta request ID miliknya dipertahankan?
2. Apakah batasannya per permintaan, penyewa (tenant), objek, jendela waktu, atau sisa kuota?
3. Bisakah klien menggunakan potongan (chunks), melanjutkan, dan meminta informasi sesi unggahan?
4. Apakah batasannya merupakan konfigurasi tetap atau kapasitas/kuota sementara?
5. Bisakah bita yang diterima menimbulkan efek samping pada penagihan, penguncian (locks), atau metadata objek?

Jawaban 30 detik

"413 berarti server menolak memproses konten yang terlalu besar. Batasan tetap tidak boleh membuat klien menunggu; kondisi sementara dapat menyertakan Retry-After. Edge harus menolak lebih awal dengan kode yang stabil, request ID, dan batasan publik, sementara aplikasi tetap memvalidasi bita sebenarnya. File berukuran besar menggunakan sesi unggahan, potongan data, dan penyelesaian yang idempoten. Setelah terputus, periksa status sebelum mengirim ulang; jangan pernah mengirim ulang potongan data yang sudah dikonfirmasi. Saya mengukur 413 berdasarkan lapisan, penyewa, dan ukuran."

Desain langkah-demi-langkah

1. Menentukan batasan berlapis

Batas maksimum tetap, kuota penyewa, kebijakan objek, dan kapasitas runtime membutuhkan pemilik yang jelas. Edge dapat menolak berdasarkan Content-Length, tetapi aplikasi juga harus memeriksa bita yang diterima, ukuran setelah didekompresi, dan kebijakan konten. Sertakan request ID dalam kesalahan; jangan mengungkapkan node internal, kapasitas disk, atau data penyewa lain.

2. Menggunakan Retry-After dengan benar

RFC 9110 memungkinkan server untuk menghasilkan Retry-After ketika kondisi 413 bersifat sementara. Nilainya dapat berupa tanggal HTTP atau detik penundaan. Batas maksimum tetap memerlukan perubahan permintaan atau pemecahan menjadi potongan data, bukan menunggu. Gunakan header untuk kuota yang diketahui atau jendela pemulihan pemeliharaan, dan minta klien membatasi (cap) serta memvalidasi penundaan tersebut.

HTTP/1.1 413 Content Too Large
Retry-After: 120
Content-Type: application/problem+json
X-Request-Id: req-81a

3. Membuat kesalahan dapat ditindaklanjuti (actionable)

Kembalikan kode yang stabil, cakupan, mode unggahan yang diizinkan, ukuran potongan maksimum, dan titik masuk sesi unggahan. Jangan pernah mengekspos nama implementasi gateway, stack trace, atau kesalahan basis data. Klien dapat mengompresi, mengubah ukuran, memotong, atau meminta kuota berdasarkan kode tersebut alih-alih mencoba kembali bodi yang sama terus-menerus.

4. Menyediakan unggahan yang dapat dilanjutkan (resumable)

Buat sesi unggahan terlebih dahulu dan kembalikan ID-nya, masa kedaluwarsa, rentang ukuran potongan, dan kueri untuk potongan yang telah selesai. Setiap potongan membawa digest dan kunci idempotensi; penyelesaian hanya merujuk pada potongan yang telah diverifikasi. Pada 413, klien dapat memperkecil potongan baru atau membuat sesi baru tanpa mentransmisikan ulang data yang telah dikonfirmasi.

5. Menangani lapisan yang tidak konsisten

Gateway dapat mengembalikan 413 sebelum aplikasi, sedangkan aplikasi dapat menolak setelah dekompresi, kuota, atau pemeriksaan kebijakan. Model kesalahan bersama tidak dapat berasumsi bahwa setiap lapisan mengetahui batas akhir. Kembalikan batasan saat ini pada pembuatan sesi, pantau sumber 413, dan jangan menyimpan nilai sementara dari satu lapisan dalam cache sebagai batas global permanen.

6. Menghubungkan percobaan ulang, penagihan, dan metrik

Klasifikasikan 413 pada klien: ubah permintaan untuk batasan tetap, ikuti Retry-After untuk batasan sementara, dan periksa status sesi setelah kegagalan sesi. Gunakan idempotensi untuk penyelesaian agar penagihan tidak terduplikasi, dan kedaluwarsakan sesi yang ditinggalkan. Lacak lapisan sumber, penyewa, ukuran permintaan, bita yang diunggah, kepatuhan Retry-After, transmisi ulang potongan, dan pemulihan akhir untuk mendeteksi pergeseran batasan.

Model jawaban berkualitas tinggi

"Pertama-tama saya mengidentifikasi lapisan yang mengeluarkan kesalahan dan jenis batasannya. Batas maksimum tetap mengembalikan 413 dengan batasan publik atau titik masuk potongan; hanya kuota atau kapasitas sementara yang mengembalikan Retry-After. File berukuran besar menggunakan sesi dan potongan data dengan digest serta idempotensi, dan klien yang terputus akan mengueri potongan yang telah dikonfirmasi. Edge menolak lebih awal, sementara aplikasi memeriksa bita aktual dan yang didekompresi. Bodi kesalahan hanya mengekspos kode stabil, request ID, dan langkah berikutnya. Saya mengukur sumber, distribusi ukuran, kepatuhan menunggu, penyelesaian duplikat, dan tingkat pemulihan."

Kesalahan umum

• Menambahkan Retry-After ke setiap 413 → batas tetap menyebabkan penantian yang sia-sia → gunakan waktu hanya untuk kondisi sementara.
• Menulis batas secara statis (hard-code) pada klien → lapisan mengalami pergeseran → kembalikan batasan sesi dan pantau sumbernya.
• Mengirim ulang seluruh bodi → bandwidth dan efek samping berlipat ganda → gunakan potongan data, kueri, dan penyelesaian idempoten.
• Hanya memeriksa Content-Length → bita aktual atau yang didekompresi dapat melebihi batas → validasi selama dan setelah penyerapan (ingestion).
• Mengekspos batas internal → topologi dan kapasitas bocor → kembalikan kode yang stabil dan request ID.

Pertanyaan lanjutan dan tanggapan

Apa yang harus dilakukan klien saat 413 tidak memiliki Retry-After?

Jangan menebak penundaan. Perlakukan ini sebagai batas tetap atau tidak diketahui, gunakan kode kesalahan dan status sesi, lalu beralihlah ke permintaan yang lebih kecil, potongan data, atau alur kuota eksplisit. Otomatiskan penantian hanya jika server memberikan waktu pemulihan.

Bagaimana jika sebuah potongan juga melebihi batas salah satu lapisan?

Kembalikan rentang yang saat ini diizinkan saat pembuatan sesi dan pilih potongan yang tidak lebih besar dari batas efektif terkecil. Jika kebijakan berubah, pertahankan potongan yang telah dikonfirmasi dan lanjutkan dengan parameter sesi baru alih-alih mengirim ulang potongan lama.

Gateway mengembalikan 413 tetapi aplikasi tidak memiliki catatan. Bagaimana Anda mendebugnya?

Bandingkan request ID, bita yang diterima, dan sumber respons di seluruh edge, gateway, dan aplikasi. Jika aplikasi tidak memiliki catatan, periksa batas gateway, perutean, dan penerusan bodi terlebih dahulu; log aplikasi yang hilang tidak membuktikan adanya penolakan oleh aplikasi.