Pertanyaan dan kapan ini berlaku
Rancang alur pesan asinkron di mana pesan masuk ke dead-letter queue (DLQ) setelah batas percobaan ulang tertentu dan operator dapat memutar ulang pesan terpilih setelah memperbaiki penyebabnya. Jelaskan isolasi, investigasi, pemilihan batch, efek samping duplikat, dan perlindungan untuk lalu lintas normal.
Topik wawancara pengembangan perangkat lunak Amazon menekankan penerapan pengetahuan untuk memecahkan masalah. AWS mendokumentasikan DLQ sebagai isolasi untuk pesan yang tidak dikonsumsi dengan batas percobaan ulang dan alarm; Google Pub/Sub mendokumentasikan dead-letter topics serta semantik pemutaran ulang atau pencarian (seek). Kuncinya adalah loop pemulihan operasional, bukan diagram antrean semata.
Apa yang dinilai oleh pewawancara
- Klasifikasi error sementara, pesan beracun (poison message), penolakan bisnis, dan kedaluwarsa.
- Metadata untuk versi, tenant, partisi, trace, jumlah percobaan, dan alasan kegagalan.
- Kontrol pemutaran ulang: idempotensi, cakupan, laju, persetujuan, dan kondisi berhenti.
- Pengurutan, retensi, pengiriman duplikat, dan semantik at-least-once.
- Metrik yang membuktikan pemulihan, bukan sekadar memindahkan pesan kembali.
Pertanyaan untuk diklarifikasi sebelum menjawab
- Apakah pengirimannya at-least-once, at-most-once, atau exactly-once tingkat bisnis?
- Kegagalan mana yang dapat dicoba ulang?
- Berapa lama pesan disimpan dan kapan pesan tersebut kehilangan nilainya?
- Apakah urutan diperlukan untuk kunci agregat?
- Bisakah konsumen membuat efek samping yang idempoten?
- Siapa yang boleh memeriksa, memutar ulang, atau menghapus pesan?
- Apa saja SLO normal, kapasitas antrean, dan kapasitas pemutaran ulang?
- Apakah pemutaran ulang yang gagal masuk ke DLQ yang sama atau replay-DLQ?
Kerangka jawaban 30 detik
“Saya mendefinisikan semantik pengiriman, retensi, dan kunci pengurutan terlebih dahulu. Error yang dapat dicoba ulang menggunakan backoff berbatas; pesan beracun dan penolakan bisnis masuk ke DLQ dengan alasan, jumlah percobaan, versi, dan ID trace. Setelah perbaikan, operator membuat batch pemutaran ulang yang dibatasi cakupannya, memvalidasi sampel secara terisolasi, dan memutar ulang pada laju terbatas. Konsumen melindungi efek samping dengan kunci idempotensi. Saya memantau usia DLQ, kegagalan pemutaran ulang, duplikat, dan latensi downstream, serta menjeda saat ambang batas terlampaui.”
Jawaban mendalam, langkah demi langkah
Langkah 1: Tentukan state machine kegagalan
Pisahkan status normal, percobaan ulang, DLQ, perbaikan manual, dan replay-DLQ. Kegagalan bisnis permanen tidak boleh dicoba ulang tanpa henti.
Langkah 2: Tentukan metadata pesan
Simpan ID event, kunci idempotensi bisnis, waktu pembuatan, tenant atau partisi, versi skema, jumlah percobaan, ID trace asli, dan kelas error. Pertahankan muatan asli secara abadi (immutable).
Langkah 3: Tetapkan aturan percobaan ulang dan DLQ
Pilih penerimaan maksimum, backoff, dan retensi. AWS SQS mendokumentasikan batasan antrean sumber dan Region serta merekomendasikan alarm DLQ. Pesan yang kedaluwarsa atau dibatalkan memerlukan disposisi yang diaudit.
Langkah 4: Buat pemutaran ulang menjadi aman
Permintaan pemutaran ulang mencakup filter, versi konsumen target, batas laju, ukuran batch, pemberi persetujuan, dan masa kedaluwarsa. Validasi sampel terlebih dahulu, lalu putar ulang dalam batch. Isolasi kapasitas pemutaran ulang dari lalu lintas normal.
| Kontrol | Tujuan | Tindakan saat gagal |
|---|---|---|
| Kunci idempotensi | Mencegah efek samping duplikat | Tolak atau kembalikan hasil sebelumnya |
| Batas laju | Melindungi konsumen dan dependensi | Jeda pemutaran ulang |
| Cakupan batch | Membatasi radius dampak | Persempit filter |
| Persetujuan dan audit | Menetapkan akuntabilitas | Blokir tindakan yang tidak sah |
| Replay-DLQ | Mengisolasi kegagalan berulang | Buat batch diagnosis baru |
Langkah 5: Tangani pengurutan dan konkurensi
Saat urutan penting, buat partisi berdasarkan kunci agregat dan cegah konsumen normal serta pemutaran ulang memproses kunci yang sama secara bersamaan. Jangan mengklaim pengiriman end-to-end exactly-once hanya dari antrean saja.
Langkah 6: Lindungi efek samping
Gunakan ID event atau kunci idempotensi bisnis untuk penulisan bersyarat. Pembayaran dan email memerlukan kunci permintaan idempoten dan pencarian hasil; menghapus pesan bukanlah sebuah rollback.
Langkah 7: Beroperasi dengan observabilitas
Pantau kedalaman DLQ, usia pesan tertua, kelas error, throughput pemutaran ulang, kegagalan pemutaran ulang, efek duplikat, dan latensi downstream. Catat operator, alasan, cakupan, waktu, hasil, dan event penghentian untuk setiap batch.
Langkah 8: Anggarkan kapasitas dan hentikan dengan aman
Perkirakan kapasitas pemutaran ulang dan jaga agar konsumen baru tetap kompatibel dengan skema lama. Jeda saat penyebab belum teratasi, dependensi kelebihan beban, atau tingkat duplikasi meningkat; pertahankan bukti.
Contoh jawaban berkualitas tinggi
“Ini adalah alur event pesanan at-least-once. Waktu tunggu jaringan habis (timeout) dicoba ulang hingga lima kali dengan backoff; error skema, kegagalan otorisasi, dan event kedaluwarsa masuk ke DLQ. Setiap pesan menyimpan ID event, ID pesanan, tenant, versi skema, waktu pertama masuk antrean, jumlah percobaan, kelas error, dan ID trace.
Setelah perbaikan, operator memilih tenant dan rentang waktu, versi target, batas laju, pemberi persetujuan, dan masa kedaluwarsa. Lima puluh pesan divalidasi pada konsumen yang terisolasi, kemudian pemutaran ulang berjalan pada sepuluh persen dari lalu lintas normal. Status pesanan menggunakan penulisan bersyarat yang dikunci oleh ID event, dan permintaan pembayaran menggunakan kembali kunci idempotensi bisnis. Pemrosesan normal dan pemutaran ulang untuk satu pesanan tidak dapat berjalan secara bersamaan.
Peringatan mencakup usia pesan tertua, kegagalan pemutaran ulang, penulisan duplikat, dan latensi dependensi. Ambang batas mana pun akan menjeda batch dan mengarahkan kegagalan berulang ke replay-DLQ. Catatan batch berisi filter, versi, operator, hasil, dan alasan berhenti.”
Kesalahan umum
- Memperlakukan DLQ sebagai tempat sampah tanpa bukti.
- Mencoba ulang pesan beracun tanpa henti.
- Memasukkan kembali ke antrean tanpa batasan cakupan, persetujuan, atau kontrol laju.
- Mengasumsikan antrean menyediakan end-to-end exactly-once secara otomatis.
- Mengabaikan idempotensi sehingga menimbulkan tagihan atau email ganda.
- Mengabaikan kunci pengurutan.
- Hanya memantau panjang antrean.
- Berbagi kapasitas antara pemutaran ulang dan lalu lintas normal tanpa perlindungan.
Pertanyaan lanjutan dan cara menjawabnya
Tindak lanjut 1: Mengapa tidak menambah jumlah percobaan ulang?
Percobaan ulang cocok untuk kegagalan sementara; pesan beracun dan kegagalan bisnis permanen hanya akan menghabiskan kapasitas. Tetapkan batas berdasarkan jenis kesalahan, retensi, dan biaya tunggu bisnis.
Tindak lanjut 2: Bagaimana Anda mempertahankan urutan untuk satu pesanan?
Lakukan partisi berdasarkan kunci pesanan, blokir pemrosesan normal dan pemutaran ulang yang berjalan bersamaan, dan jelaskan bagaimana transisi status menolak event yang usang.
Tindak lanjut 3: Bagaimana jika dependensi tidak idempoten?
Gunakan deduplikasi lokal dan pencarian hasil; jika tidak memungkinkan, wajibkan rekonsiliasi manual, kompensasi, atau mekanisme idempotensi dari penyedia layanan.
Tindak lanjut 4: Bagaimana jika pemutaran ulang gagal lagi?
Kirim ke replay-DLQ terpisah, pertahankan batch asli dan error baru, jeda filter yang terdampak, dan beri tahu pemilik sistem.
Tindak lanjut 5: Bagaimana Anda memilih laju pemutaran ulang?
Gunakan kapasitas konsumen, kuota dependensi, kapasitas cadangan (headroom) normal, dan waktu pemulihan. Lakukan uji beban pada batch kecil sebelum meningkatkan laju.
Tindak lanjut 6: Kapan Anda boleh membuang pesan?
Hanya setelah ada keputusan bisnis eksplisit bahwa pesan tersebut sudah kedaluwarsa, dibatalkan, atau tidak bernilai lagi, lengkap dengan bukti audit dan alasan yang dicatat.