Wawancara Umum: Bagaimana Seharusnya Anda Menjelaskan HTTP 507 Insufficient Storage?

Petunjuk dan konteks

Pertanyaan fundamental HTTP dan API ini cocok untuk peran backend, platform, SRE, dan infrastruktur. Suatu permintaan pada prinsipnya valid, tetapi server tidak dapat menyimpan status sumber daya yang dihasilkan karena kuota, sistem berkas, anggaran memori, atau batas aplikasi telah habis. Jelaskan kapan 507 bermakna, kapan status lain lebih tepat, dan cara memulihkannya tanpa menduplikasi operasi penulisan (write).

Apa yang dinilai oleh pewawancara

• Bisakah Anda memisahkan habisnya kapasitas di sisi server dari permintaan yang secara intrinsik terlalu besar?
• Apakah Anda tahu bahwa 507 berasal dari WebDAV dan merupakan kondisi server sementara alih-alih kesalahan validasi generik?
• Bisakah Anda mendefinisikan percobaan ulang (retry), backoff, idempotensi, dan remediasi yang dihadapi pengguna tanpa menyembunyikan penyebabnya?
• Bisakah Anda melacak batas tersebut di seluruh lapisan aplikasi, penyimpanan, kuota, proxy, dan cache?

Pertanyaan klarifikasi yang perlu diajukan

Tanyakan operasi mana yang gagal, apakah representasi yang diminta valid, batas sumber daya mana yang tercapai, apakah batas tersebut spesifik untuk penyewa (tenant), dan apakah operasi telah mengomit status parsial. Konfirmasikan apakah klien dapat mencoba lagi dengan aman dan apakah layanan mengekspos sinyal kuota atau kapasitas. Jika muatan melebihi kebijakan atau batas parser terlepas dari kapasitas bebas, gunakan 413; jika layanan sementara tidak tersedia karena alasan pemrosesan yang lebih luas, 503 mungkin lebih cocok. Jangan memilih 507 hanya karena ada peringatan disk di suatu tempat di armada server.

Kerangka jawaban 30 detik

Saya akan mengembalikan 507 ketika operasi yang diminta sebenarnya valid tetapi server tidak dapat mencatat status sumber daya yang dihasilkan karena penyimpanan yang tersedia atau batas server yang berlaku telah habis. Saya akan membedakannya dari 413, yaitu tentang permintaan yang terlalu besar, dan dari 503, yang mewakili ketidaktersediaan sementara yang lebih luas. Respons harus mengekspos jenis masalah yang stabil dan ID permintaan tanpa membocorkan jalur internal. Klien hanya mencoba lagi ketika operasi tersebut idempoten atau memiliki kunci idempotensi, dengan backoff terbatas; operator mengukur dimensi pasti yang habis, membebaskan atau memperluas kapasitas, dan memverifikasi penulisan lengkap sebelum menyatakan pemulihan.

Pembahasan mendalam langkah demi langkah

1. Klasifikasikan kegagalan. RFC 4918 mendefinisikan 507 untuk metode yang tidak dapat mencatat status sumber daya setelah eksekusi karena tujuan kekurangan ruang yang cukup. MDN mencatat bahwa implementasi juga menggunakannya untuk sumber daya server atau batas aplikasi yang habis. Kondisi kuncinya adalah tindakan valid yang diblokir oleh batas kapasitas sisi server.
2. Pisahkan status yang berdekatan. Kembalikan 413 jika konten terlalu besar terlepas dari kapasitas saat ini. Kembalikan 409 atau 412 jika terjadi konflik status atau prakondisi gagal. Kembalikan 503 jika layanan tidak dapat memproses permintaan secara umum dan dapat menyediakan Retry-After. Respons 507 tidak boleh menjadi penampung umum untuk setiap kegagalan penulisan.
3. Jadikan kegagalan dapat ditindaklanjuti. Gunakan tipe masalah yang stabil, judul yang dapat dibaca manusia, ID permintaan, dan petunjuk percobaan ulang hanya jika kapasitas diperkirakan akan pulih. Kuota tenant dapat mencakup pengidentifikasi kuota yang aman atau tautan remediasi, sementara jalur sistem berkas, nama host, dan detail kebijakan rahasia tetap bersifat internal.
4. Lindungi percobaan ulang. Pengunggahan yang mengalami timeout dapat memiliki status komit yang tidak diketahui. Wajibkan kunci idempotensi atau token pengunggahan yang dapat dilanjutkan (resumable), pertahankan status operasi, dan buat klien menanyakan status sebelum mengulanginya. Terapkan backoff eksponensial dengan batas waktu (deadline); percobaan ulang tanpa batas dapat memperparah sistem yang sudah penuh.
5. Lacak batas sumber daya. Catat byte atau inode bebas, kuota penyimpanan objek, penggunaan staging database/blob, batas memori, alokasi tenant, dan lapisan yang mengeluarkan 507. Bandingkan log aplikasi dengan metrik penyimpanan dan ID permintaan sehingga kesalahan yang dihasilkan proxy tidak disalahartikan sebagai keputusan origin.
6. Pulihkan dan verifikasi. Kuras (drain) atau tolak penulisan baru jika diperlukan, perluas atau klaim kembali kapasitas, dan jalankan kembali penulisan terbatas menggunakan kunci idempotensi asli. Verifikasi checksum objek, metadata, visibilitas, dan penghitungan kuota. Buat peringatan jika terjadi kembali dan uji bahwa tenant yang penuh tidak dapat mengonsumsi reservasi tenant lain.

Contoh jawaban yang kuat

Saya hanya akan menggunakan 507 jika permintaan valid tetapi server tidak dapat mempertahankan status yang dihasilkan karena batas penyimpanan atau sumber daya server habis. Muatan yang selalu terlalu besar adalah 413, dan kondisi pemeliharaan atau kelebihan beban yang luas mungkin adalah 503. Saya akan mengembalikan tipe masalah yang stabil dan ID permintaan, ditambah petunjuk percobaan ulang hanya jika pemulihan masuk akal:

HTTP/1.1 507 Insufficient Storage
Content-Type: application/problem+json
Cache-Control: no-store
Retry-After: 120

{
  "type": "https://api.example.com/problems/storage-exhausted",
  "title": "The resource could not be stored",
  "status": 507,
  "detail": "The workspace storage limit prevented this operation.",
  "request_id": "req-7f2"
}

Klien tidak boleh secara membabi buta mengirim ulang unggahan yang status komitnya tidak diketahui. Klien mencoba lagi dengan kunci idempotensi yang sama atau meminta status operasi terlebih dahulu. Operator mengorelasikan permintaan dengan metrik kuota, staging, penyimpanan objek, database, dan inode, lalu memverifikasi checksum, visibilitas, dan penghitungan setelah kapasitas dipulihkan. Jika gateway mengeluarkan 507 sementara origin mengembalikan 200, saya memperlakukan gateway sebagai lapisan yang mengeluarkan dan menguji setiap hop secara independen.

Kesalahan umum

• Mengembalikan 507 untuk permintaan yang terlalu besar → perubahan kapasitas tidak dapat membuat muatan itu valid → gunakan 413 untuk kebijakan ukuran permintaan tetap.
• Mencoba lagi setiap 507 secara langsung → sumber daya yang penuh menjadi lebih diperebutkan → gunakan backoff terbatas dan batas waktu operasi.
• Memutar ulang unggahan setelah waktu habis → penulisan asli mungkin telah dikomit → kueri status atau gunakan kembali kunci idempotensi.
• Mengatakan "disk penuh" tanpa menemukan batasannya → kuota, inode, staging, dan penyimpanan objek dapat gagal secara independen → identifikasi lapisan yang mengeluarkan dan dimensi yang habis.
• Melaporkan jalur mentah dan nama host ke klien → topologi internal dan data tenant dapat bocor → kembalikan tipe masalah yang stabil dan ID permintaan, sambil menyimpan diagnostik dalam log yang dilindungi.

Pertanyaan lanjutan dan jawaban

Haruskah klien mencoba lagi HTTP 507?

Hanya jika operasi aman untuk dicoba lagi dan kapasitas diperkirakan akan pulih. Gunakan kunci idempotensi atau pencarian status untuk penulisan, backoff eksponensial, dan batas waktu. Jika kesalahan mewakili kuota ketat tenant, tampilkan remediasi alih-alih mencoba lagi.

Bagaimana cara membedakan 507 dari 503?

507 mengidentifikasi ketidakmampuan untuk mencatat status sumber daya yang valid karena batas penyimpanan atau server habis. 503 adalah ketidakmampuan sementara yang lebih luas untuk melayani permintaan dan dapat mencakup pemeliharaan atau kelebihan beban. Gunakan batas kegagalan yang terukur dan kebijakan layanan yang konsisten daripada menebak hanya dari lapisan HTTP.

Bagaimana jika origin berhasil tetapi proxy mengembalikan 507?

Ambil ID permintaan dan bandingkan permintaan langsung ke origin, proxy, dan cache-cold. Proxy adalah lapisan yang mengeluarkan dan mungkin memiliki buffer atau kuotanya sendiri. Rekonsiliasi status akhir klien sebelum mencoba lagi, karena origin mungkin sudah berisi sumber daya tersebut.