Perintah dan konteks
Pertanyaan ini cocok untuk wawancara backend, platform, dan sistem terdistribusi. Pewawancara menginginkan batasan yang jelas: SQS memperlakukan ID deduplikasi yang sama sebagai duplikat dalam interval deduplikasi dan terus melacak ID tersebut bahkan setelah pesan diterima dan dihapus; hal itu tidak membuat efek samping pada basis data eksternal, pembayaran, atau email secara inheren menjadi exactly-once.
Apa yang sedang diuji oleh pewawancara
Jawaban yang kuat memisahkan antara deduplikasi produsen, pengurutan FIFO, visibility timeout konsumen, konfirmasi penghapusan, dan idempotensi bisnis. AWS mendefinisikan ID deduplikasi sebagai token yang mencegah pengiriman duplikat; ketika deduplikasi berbasis konten diaktifkan dan tidak ada ID yang diberikan, SQS dapat memperolehnya dengan melakukan hashing pada isi pesan (message body). Jawaban harus mencakup interval, percobaan ulang (retry), dan observabilitas, bukan sekadar mengatakan "FIFO tidak pernah menduplikasi."
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
Batasan semantik
Tanyakan apakah persyaratannya adalah penekanan duplikat di tingkat antrean, pemrosesan at-least-once, atau efek bisnis satu kali saja. Pisahkan antara "satu pesan" dan "satu penagihan".
Input deduplikasi
Konfirmasikan apakah produsen membuat MessageDeduplicationId yang stabil, apakah deduplikasi berbasis konten diaktifkan, bagaimana grup pesan dipilih, dan apakah percobaan ulang terjadi dalam interval lima menit.
Titik kegagalan
Gambarkan linimasa penerimaan, pemrosesan, penulisan efek samping, dan DeleteMessage. Tanyakan apa yang terjadi jika konsumen crash, visibility timeout habis, percobaan ulang jaringan, dan timeout pada sistem downstream.
Kerangka jawaban 30 detik
"ID deduplikasi FIFO menekan pesan yang sama agar tidak diterima kembali selama interval lima menit dan terus melacak ID tersebut; ini menangani pengiriman duplikat di tingkat antrean dan pengurutan, bukan efek samping eksternal yang exactly-once. Saya akan menggunakan kunci bisnis yang stabil untuk catatan idempotensi, menempatkan status efek samping dan outbox dalam satu transaksi atau batasan lain yang aman terhadap percobaan ulang, dan menghapus pesan hanya setelah berhasil. Crash mungkin menyebabkan pengiriman ulang, tetapi upaya yang berulang akan membaca catatan yang sudah selesai."
Jawaban mendalam langkah demi langkah
Langkah 1: Nyatakan jaminan yang dapat diuji
Katakan bahwa ID deduplikasi yang sama diperlakukan sebagai duplikat selama interval deduplikasi lima menit; SQS terus melacak ID tersebut setelah penerimaan dan penghapusan. Jangan menggambarkan interval tersebut sebagai deduplikasi permanen.
Langkah 2: Pisahkan kendali produsen dan konsumen
Produsen menggunakan ID yang stabil untuk satu perintah bisnis; hashing konten hanya berfungsi jika body sepenuhnya mewakili perintah tersebut. Konsumen memerlukan batasan unik yang tahan lama (durable unique constraint) pada pesanan, payment intent, atau ID perintah karena percobaan ulang setelah interval berakhir masih bisa merupakan tindakan bisnis yang sama.
Langkah 3: Tangani celah saat crash (crash window)
Jika konsumen menulis ke basis data lalu mengalami crash, pesan mungkin muncul kembali setelah visibility timeout-nya habis. Tempatkan status efek samping dan kunci idempotensi dalam satu transaksi, atau gunakan outbox untuk publikasi yang dapat diputar ulang; hapus hanya setelah commit berhasil.
Langkah 4: Tangani pengurutan dan pesan beracun (poison messages)
Gunakan MessageGroupId yang sama jika urutan penting dan atur visibility timeout yang sesuai dengan beban kerja. Pindahkan pesan yang gagal berulang kali ke dead-letter queue beserta ID asli, jumlah penerimaan, dan alasan kegagalan agar percobaan ulang tidak memblokir grup selamanya.
Langkah 5: Verifikasi dan amati
Uji percobaan ulang produsen, crash konsumen setelah penulisan, timeout DeleteMessage, dan pemutaran ulang di luar interval. Pantau kunci bisnis duplikat, ApproximateReceiveCount, kedalaman DLQ, visibility timeout, dan latensi ujung-ke-ujung; peringatan (alert) harus membedakan duplikat antrean dari duplikat bisnis.
Contoh jawaban berkualitas tinggi
Saya memperlakukan deduplikasi lima menit SQS sebagai pengaman transportasi, bukan jaminan pembayaran satu kali. Produsen membuat ID perintah yang stabil untuk setiap payment intent dan menggunakannya kembali saat mencoba lagi. Konsumen pertama-tama menerapkan ID perintah unik dalam tabel inbox, lalu menulis status pesanan dan peristiwa outbox dalam transaksi yang sama, dan menghapus pesan setelah commit. Jika proses crash setelah penulisan, pengiriman ulang akan menemukan catatan yang telah selesai dan tidak menagih lagi. Saya akan memantau perintah duplikat, jumlah penerimaan, dan DLQ, serta menginjeksikan kegagalan selama percobaan ulang di dalam jendela waktu, di luar jendela waktu, dan pada DeleteMessage.
Kesalahan umum
- Kesalahan: Mengatakan FIFO berarti exactly-once permanen. → Mengapa gagal: Mengabaikan interval lima menit dan crash pada konsumen. → Solusi: Sebutkan batasan waktu ID dan tambahkan idempotensi bisnis.
- Kesalahan: Menghasilkan ID deduplikasi baru untuk setiap percobaan ulang. → Mengapa gagal: Satu perintah menjadi beberapa pesan berbeda. → Solusi: Gunakan kembali ID perintah yang stabil.
- Kesalahan: Menghapus pesan sebelum pemrosesan selesai. → Mengapa gagal: Kegagalan downstream berubah menjadi kehilangan pesan. → Solusi: Hapus setelah commit berhasil dan biarkan pengiriman ulang terjadi jika timeout.
- Kesalahan: Hanya mengandalkan hash dari body pesan. → Mengapa gagal: Timestamp atau bidang yang tidak relevan dapat melewati deduplikasi. → Solusi: Tentukan ID stabil yang eksplisit untuk perintah bisnis.
Tindak lanjut dan tanggapan
Tindak lanjut 1: Bagaimana jika perintah yang sama tiba setelah lima menit?
Gunakan catatan idempotensi bisnis yang persisten untuk memutuskan apakah proses sudah selesai; deduplikasi antrean mengurangi pengulangan dalam jendela waktu pendek tetapi tidak dapat menggantikan status bisnis jangka panjang.
Tindak lanjut 2: Mengapa tidak menghapus sebelum memproses?
Menghapus terlebih dahulu mengubah kegagalan downstream menjadi kehilangan pesan. Kecuali jika kehilangan pesan dapat diterima secara eksplisit dan ada sumber lain yang andal, lakukan pemrosesan dengan mekanisme retry sebelum menghapus.
Tindak lanjut 3: Masalah apa yang diselesaikan oleh outbox?
Outbox melakukan commit pada status bisnis dan event yang tertunda dalam satu transaksi basis data sehingga publikasi dapat dicoba ulang dengan aman; konsumen downstream tetap memerlukan idempotensi berbasis ID event.
Tindak lanjut 4: Bagaimana Anda membuktikan tidak ada penagihan ganda?
Injeksikan kegagalan setelah penulisan, selama timeout penghapusan, dan setelah replay di luar jendela waktu. Verifikasi batasan keunikan basis data, kunci idempotensi penyedia pembayaran, dan log audit, alih-alih hanya mengandalkan metrik antrean.