Konteks dan cakupan
Anda mengelola API pembayaran, penggantian kata sandi, atau pembuatan pesanan. Edge mengaktifkan TLS 1.3 0-RTT, dan sebuah gateway dapat meneruskan permintaan yang memuat Early-Data: 1. Jelaskan kapan harus mengembalikan 425, kapan harus melanjutkan proses, dan bagaimana klien melakukan retry setelah handshake selesai. Ini relevan untuk wawancara backend, platform, dan infrastruktur API.
RFC 8470 mendefinisikan 425 sebagai penolakan server untuk mengambil risiko memproses permintaan yang mungkin di-replay; ini bukan kode retry generik untuk "server sedang sibuk". Asumsikan gateway dapat mempertahankan sinyal Early-Data dan layanan dapat membedakan operasi baca-saja dari efek samping.
Apa yang sedang diuji oleh pewawancara
- Apakah Anda memisahkan manfaat latensi 0-RTT dari risiko replay alih-alih memperlakukan setiap kode 4xx sebagai input klien biasa.
- Apakah Anda dapat memetakan tanggung jawab klien, gateway, dan aplikasi terkait menunggu, melakukan retry, dan idempotensi.
- Apakah Anda dapat menerjemahkan kondisi RFC, non-cacheability, dan timing retry menjadi kebijakan API yang dapat diuji.
Jawaban yang lemah sekadar menghafal "425 berarti Too Early". Jawaban yang kuat membuat keputusan berdasarkan efek samping, sinyal Early-Data, kunci idempotensi, dan jendela retry yang terbatas, lalu menjelaskan bagaimana konfigurasi yang buruk dapat menyebabkan penagihan ganda pada pelanggan.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
- Apakah permintaan membawa
Early-Data: 1, atau dapatkah edge membuktikan bahwa permintaan tersebut tiba di early data? RFC 8470 menyarankan untuk tidak membuat respons 425 tanpa sinyal tersebut. - Apakah operasi tersebut menimbulkan efek samping eksternal? Pembacaan pesanan dapat dilanjutkan; penagihan, penggantian kata sandi, atau penerbitan kupon harus menunggu handshake atau menggunakan catatan idempotensi yang ketat.
- Apakah gateway akan melakukan retry secara otomatis? Jika ya, verifikasi bahwa gateway melakukan retry setelah handshake dan bahwa gateway serta SDK tidak masing-masing melakukan retry.
- Apakah klien mendukung kunci idempotensi dan batas retry? Tanpa hal tersebut, menonaktifkan 0-RTT untuk operasi tersebut lebih aman daripada memperlakukan 425 sebagai izin untuk melakukan retry tanpa batas.
Jawaban 30 detik
"Pertama-tama saya memverifikasi bahwa permintaan datang melalui TLS early data dengan Early-Data: 1, lalu mengklasifikasikan efek sampingnya. Pekerjaan baca-saja dapat dilanjutkan; pembayaran dan penggantian kata sandi akan menunggu di gateway atau menerima 425. Klien hanya melakukan retry setelah handshake selesai, dan layanan menggunakan kunci idempotensi beserta batasan keunikan (uniqueness constraint) untuk mencegah eksekusi duplikat. Gateway mempertahankan sinyal, mengelola satu kebijakan retry, dan kami memantau rasio 425, keberhasilan retry, serta efek samping duplikat. Jika rangkaian sistem tidak dapat membuktikan kondisi-kondisi ini, saya menonaktifkan 0-RTT untuk endpoint tulis."
Solusi langkah demi langkah
1. Mengidentifikasi sinyal risiko
RFC 8470 mengharuskan perantara (intermediary) untuk mempertahankan arti Early-Data saat meneruskan early data. Layanan hanya boleh mempertimbangkan 425 jika permintaan berpotensi untuk di-replay. Mengembalikan 425 tanpa bukti akan mengubah kegagalan jaringan biasa menjadi penolakan keamanan yang menyesatkan.
2. Mengklasifikasikan berdasarkan efek samping
Klasifikasikan endpoint sebagai baca-saja, dapat diulang dengan aman, atau tidak aman untuk diulang. GET /orders/123 biasanya bersifat baca-saja; menerbitkan kupon sekali pakai, menagih kartu, atau mengganti kata sandi tidak aman untuk diulang. Kelas yang tidak aman harus menunggu handshake selesai atau menyimpan kunci idempotensi sebelum mengeksekusi efek samping apa pun.
3. Menetapkan satu pemilik retry
Setelah menerima 425, klien menunggu TLS handshake dan mengirimkan permintaan kembali; retry tidak boleh menggunakan early data. Gateway dapat mengambil tanggung jawab atas retry tersebut, tetapi kontraknya harus menyatakan demikian secara eksplisit, jika tidak gateway dan SDK dapat sama-sama melakukan retry. Terapkan exponential backoff, batas percobaan maksimum, dan alasan yang jelas untuk setiap retry.
4. Menjadikan idempotensi sebagai pertahanan kedua
Wajibkan kunci idempotensi untuk operasi tulis. Layanan menyimpan catatan unik berdasarkan tenant, endpoint, dan kunci, dengan setidaknya status pemrosesan, sukses, dan kegagalan yang dapat di-retry. Permintaan duplikat akan mengembalikan hasil awal atau respons eksplisit bahwa operasi sedang berlangsung. Idempotensi tidak menggantikan 425: eksekusi pertama masih dapat di-replay setelah commit database dan sebelum respons sampai ke klien.
5. Menjaga konsistensi gateway dan instance
Setiap instance harus menerapkan kebijakan Early-Data yang sama. Jika gateway tidak yakin bahwa upstream memahami sinyal tersebut, gateway harus menunggu handshake atau menolak permintaan dini; gateway tidak boleh meneruskan operasi tulis secara diam-diam ke layanan yang hanya mendukung HTTP. Catat ID permintaan, status Early-Data, alasan 425, dan hash kunci idempotensi pada log, jangan pernah mencatat isi pembayaran.
6. Menguji jalur kegagalan
Uji permintaan dengan dan tanpa Early-Data: 1, retry pertama setelah handshake, retry dari gateway, timeout klien yang diikuti dengan pengiriman ulang, dan dua instance yang mengalami race condition pada satu kunci idempotensi. Pastikan efek samping yang tidak aman hanya terjadi satu kali dan 425 tidak di-cache.
Alternatif yang lebih sederhana adalah menonaktifkan 0-RTT sepenuhnya. Opsi ini memiliki batas keamanan yang jelas tetapi menambah latensi handshake. Untuk sejumlah kecil endpoint di mana penghematan latensinya tidak signifikan, menonaktifkannya lebih aman daripada memelihara kebijakan lintas-lapisan.
Contoh jawaban berkualitas tinggi
"Saya tidak akan menggunakan 425 sebagai kesalahan throttling umum. Pertama-tama saya memeriksa Early-Data: 1, lalu mengevaluasi apakah operasi tersebut memiliki efek samping. Pembacaan pesanan dapat dilanjutkan; endpoint pembayaran dan penggantian kata sandi akan menunggu di gateway atau mengembalikan 425. Klien melakukan retry tepat setelah handshake, dengan kebijakan SDK yang terbatas. Layanan juga mewajibkan kunci idempotensi, menerapkan batasan keunikan tenant-plus-key, dan menyimpan status pemrosesan serta hasil akhir sehingga respons yang hilang tidak menyebabkan penagihan kedua. Gateway dan instance berbagi satu kebijakan, dan kami memantau rasio 425, keberhasilan retry, serta eksekusi duplikat. Jika Early-Data tidak dapat dipropagasi, saya memilih untuk menonaktifkan 0-RTT untuk operasi tulis daripada menebak-nebak."
Kesalahan umum
- Menggunakan 425 sebagai pengganti 429 → Pemicu dan tindakan klien berbeda → Gunakan 425 hanya jika ada risiko replay pada early-data.
- Mengembalikan 425 untuk setiap permintaan → Pembacaan terblokir dan klien dapat melakukan retry tanpa henti → Klasifikasikan efek samping dan batasi retry.
- Melakukan retry di 0-RTT lagi → Jendela replay tetap terbuka → Wajibkan handshake yang sudah selesai sebelum mengirim ulang.
- Menerapkan idempotensi hanya pada aplikasi → Gateway atau instance lain mungkin mengeksekusi lebih dulu → Terapkan satu kebijakan di seluruh edge, layanan, dan persistensi.
- Mencatat seluruh isi pembayaran dalam log → Debugging dapat mengekspos data sensitif → Catat pengidentifikasi, alasan, dan hash kunci yang disunting (redacted).
Pertanyaan lanjutan dan responsnya
Bagaimana jika gateway menghapus header Early-Data?
Perlakukan hal itu sebagai keterbatasan kapabilitas: gateway harus menunggu handshake atau menolak permintaan dini. Aplikasi tidak dapat menyimpulkan 0-RTT dari permintaan biasa; perbaiki propagasi sinyal sebelum mengaktifkan operasi tulis.
Bagaimana jika klien mengalami timeout dan mengirimkan kembali sebelum melihat 425?
Gunakan kunci idempotensi yang sama sehingga permintaan kedua membaca status sedang berlangsung atau hasil akhir dari permintaan pertama. Untuk operasi tulis berbahaya tanpa kunci, kembalikan kesalahan yang dapat didiagnosis dan gunakan alur kerja manual atau kompensasi; jangan menebak apakah penagihan telah terjadi.
Bagaimana jika retry sering kali berhasil tetapi memperburuk SLO latensi?
Bandingkan rasio 425, latensi p95 keberhasilan pertama, efek samping duplikat, dan keberhasilan bisnis berdasarkan endpoint dan user agent. Jika manfaat pada penulisan tidak sebanding dengan latensinya, pertahankan 0-RTT hanya untuk pembacaan yang aman atau nonaktifkan untuk kelas endpoint tersebut.