Konteks dan instruksi
Pertanyaan ini menguji apakah Anda dapat mengubah optimalisasi latensi tingkat transport menjadi batasan keamanan bisnis yang jelas. TLS 1.3 early data dapat dikirim sebelum koneksi dibuat sepenuhnya, dan RFC 8470 secara eksplisit menyoroti risiko replay. Oleh karena itu, keamanan permintaan tidak dapat diputuskan hanya dari nama metode HTTP. Bahas kelas permintaan, transisi status, idempotensi, cache dan proksi, percobaan ulang klien, pemantauan, serta fallback.
Hal yang dievaluasi pewawancara
- Apakah Anda membedakan pembacaan berulang yang tidak berbahaya dari efek samping yang berulang.
- Apakah Anda membatasi early data pada set aman yang eksplisit dan memberikan jalur penolakan yang dapat dijelaskan untuk permintaan yang tidak pasti.
- Apakah 425, kunci idempotensi, deduplikasi, dan retry backoff bekerja sama dengan baik.
- Apakah Anda dapat menjelaskan rantai proksi, log, metrik, rollback, dan kontrol peluncuran bertahap.
Pertanyaan klarifikasi yang perlu diajukan terlebih dahulu
Konfirmasikan permintaan mana yang boleh membawa early data, di mana TLS diterminasi, dan apakah proksi atau percobaan ulang pesan terjadi setelah edge. Operasi mana yang mengubah saldo, inventaris, pesanan, izin, atau notifikasi? Apakah bisnis sudah memiliki kunci idempotensi, tabel status permintaan, dan batasan unik (unique constraints)? Apakah klien, SDK, dan gateway memahami 425? Siapa yang melakukan percobaan ulang, berapa kali, dan dengan exponential backoff serta jitter seperti apa? Jika penyimpanan deduplikasi tidak tersedia, apakah layanan harus menolak, melakukan fallback ke jabat tangan penuh (full handshake), atau melanjutkan lalu lintas baca-saja?
Kerangka jawaban 30 detik
Secara default, saya akan mengecualikan permintaan yang memiliki efek samping atau yang idempotensinya tidak dapat dibuktikan dari early data. Edge mendeteksi early data dan meneruskan sinyal yang dilindungi ke aplikasi; pembacaan yang aman dapat dilanjutkan, sementara pesanan, penagihan, dan perubahan izin mengembalikan 425 atau memerlukan handshake penuh. Untuk operasi tulis yang benar-benar membutuhkan latensi rendah, klien menyediakan kunci idempotensi dan server menggunakan unique constraint serta status hasil berdurasi pendek untuk mempertahankan status “processing” dan “completed”. Klien hanya mengulang respons yang secara eksplisit dapat diulang, dengan bounded exponential backoff dan jitter. Luncurkan secara bertahap dan pantau eksekusi duplikat, 425, volume percobaan ulang, dan anomali bisnis.
Pembahasan mendalam langkah demi langkah
1. Tentukan batas kepercayaan untuk early data
Deteksi early data pada lapisan terminasi TLS dan teruskan melalui sinyal internal yang dilindungi; klien publik tidak boleh dapat memalsukan penanda “safe request”. Tentukan apakah proksi, cache, dan panggilan antar-layanan dapat menyalin atau menunda permintaan. Secara default, perlakukan sinyal yang hilang atau jalur yang tidak pasti sebagai risiko tinggi.
2. Klasifikasikan berdasarkan efek samping bisnis
Pembacaan stateless yang hasil berulangnya tidak mengubah sumber daya lebih mudah diterima. Membuat pesanan, menagih biaya, mengurangi inventaris, mengubah izin, mengirim pesan, dan memanggil sistem eksternal bersifat sensitif terhadap replay. Bahkan PUT atau DELETE harus diperiksa terhadap implementasi sebenarnya; POST tidak secara otomatis non-idempoten. Model status bisnis dan unique constraint menentukan jaminan tersebut.
3. Rancang 425 dan fallback handshake penuh
Kembalikan 425 Too Early untuk jalur yang tidak mengizinkan early data dan dokumentasikan bagaimana klien menyelesaikan full handshake sebelum mengirim ulang. Gateway tidak boleh mengulang 425 tanpa batas. Catat apakah permintaan asli mungkin telah mencapai aplikasi sehingga edge dan klien tidak sama-sama mengulang dan memperbesar beban. Ketika kapabilitas klien tidak diketahui, kegagalan eksplisit lebih aman daripada eksekusi diam-diam.
4. Gunakan kunci idempotensi dan state machine
Ikatkan kunci idempotensi ke tenant, jenis operasi, dan digest parameter permintaan. Pertahankan status processing, success, dan failure di balik unique constraint. Satu permintaan konkuren memiliki kunci tersebut; permintaan lain membaca status atau menunggu dalam batas waktu tertentu, sementara ketidakcocokan parameter akan ditolak. Tetapkan periode retensi agar hasil lama tidak melampaui jendela percobaan ulang bisnis. Commit basis data dan efek samping eksternal tetap memerlukan outbox, polling status, atau desain kompensasi.
5. Batasi percobaan ulang dan perilaku proksi
Klien hanya mengulang ketika respons dapat diulang dan operasi memenuhi aturan idempotensi, menggunakan truncated exponential backoff, jitter, dan batas total percobaan. Gateway, SDK, dan konsumen antrean tidak boleh menumpuk percobaan ulang tanpa batas; bedakan antara 425, kegagalan koneksi, rate limiting, dan penolakan bisnis. Untuk penulisan bernilai tinggi, biarkan klien mengkueri status kunci idempotensi daripada mengirim ulang efek samping aslinya.
6. Pantau, luncurkan, dan lakukan fallback
Mulailah dengan jalur baca dan kumpulan tenant yang kecil, dengan mempertahankan tombol pengalihan (switch) berdasarkan rute, klien, dan wilayah. Lacak volume early-data, rasio 425, konflik kunci duplikat, duplikat penagihan atau anomali inventaris, amplifikasi percobaan ulang, latensi handshake penuh, dan kesalahan penyimpanan deduplikasi. Jika ambang batas terlampaui, hentikan peluncuran, nonaktifkan early data, atau paksakan full handshake, dan simpan sampel audit untuk menentukan apakah suatu permintaan benar-benar dieksekusi.
Contoh jawaban berkualitas tinggi
Saya akan memperlakukan early data sebagai input yang berpotensi dapat di-replay, bukan sebagai permintaan HTTPS biasa. Edge mendeteksi dan melindungi sinyal tersebut; pembacaan dilanjutkan hanya jika risikonya dapat diterima, sementara pesanan, penagihan, inventaris, izin, dan notifikasi eksternal mengembalikan 425 dan memerlukan handshake penuh. Untuk operasi tulis yang membutuhkan latensi rendah, klien harus mengirimkan kunci idempotensi yang terikat pada tenant, operasi, dan digest parameter. Server mempertahankan status processing, success, dan failure di balik unique constraint dan menolak konflik parameter. Tentukan kondisi percobaan ulang secara terpisah untuk 425, kegagalan koneksi, dan rate limiting; klien menggunakan bounded exponential backoff dan jitter, sementara gateway menghindari percobaan ulang otomatis tanpa batas. Luncurkan secara bertahap dan pantau 425, kunci duplikat, duplikasi eksekusi bisnis, amplifikasi percobaan ulang, latensi fallback, dan kegagalan deduplikasi. Nonaktifkan early data atau paksakan full handshake jika terjadi anomali, lalu rekonsiliasi catatan audit.
Kesalahan umum
- Menganggap TLS yang terenkripsi berarti early data tidak dapat di-replay.
- Mengklasifikasikan hanya berdasarkan nama metode alih-alih efek samping bisnis yang sebenarnya.
- Membiarkan gateway dan klien mengulang 425 tanpa batas.
- Menghilangkan pengikatan tenant dan parameter dari kunci idempotensi.
- Hanya menyimpan status sukses di cache dan mengabaikan status processing atau semantik kegagalan yang dapat diulang.
- Mengukur penghematan latensi tanpa memperhitungkan penagihan duplikat, anomali inventaris, atau amplifikasi percobaan ulang.
- Melewatkan penonaktifan tingkat rute, fallback handshake penuh, dan rekonsiliasi audit.
Pertanyaan lanjutan dan jawabannya
Apa perbedaan antara 425 dan 429?
425 berarti permintaan tiba terlalu awal dalam kondisi early-data saat ini dan harus dikirim lagi setelah full handshake. 429 berarti permintaan mencapai batas laju atau kuota. Kondisi percobaan ulang, petunjuk waktu tunggu, dan makna pemantauannya berbeda, sehingga keduanya tidak boleh berbagi satu cabang percobaan ulang otomatis yang sama.
Bagaimana jika klien tidak mendukung 425?
Untuk jalur penulisan kritis, tolak early data di gateway atau paksakan full handshake alih-alih bergantung pada interpretasi klien. Sediakan perilaku kompatibilitas dalam SDK yang diperbarui. Jalur baca-saja dapat dilanjutkan, tetapi catat kapabilitas klien dan batas risikonya.
Haruskah penagihan biaya dilanjutkan jika penyimpanan idempotensi mati?
Jangan lakukan efek samping berisiko tinggi ketika deduplikasi tidak dapat dibuktikan. Kembalikan error yang dapat dicoba lagi, lakukan fallback ke full handshake dan periksa ulang, atau ubah permintaan menjadi status pending yang dapat dikueri. Pilih berdasarkan batas kerugian dan jalur pemulihan.
Bisakah permintaan early-data dieksekusi setelah layanan mengembalikan 425?
Terdapat kondisi race condition di mana permintaan telah mencapai aplikasi, sehingga aplikasi harus memeriksa ulang sinyal early-data dan status idempotensi sebelum mengeksekusi efek samping. Respons 425 tidak membatalkan operasi yang sudah dimulai. Lakukan commit efek samping melalui state machine dan unique constraint, lalu gunakan catatan audit untuk mengonfirmasi eksekusi.