Permintaan dan konteks
Produsen mengirim CloudEvents dengan percobaan ulang, payload berversi, dan lalu lintas yang tidak merata. Gateway harus memvalidasi amplop (envelope), mengisolasi penyewa, menjaga bukti pengiriman, dan membuat perilaku setidaknya-sekali (at-least-once) eksplisit bagi konsumen.
Apa yang diuji oleh pewawancara
- Mengubah amplop protokol menjadi kontrak penyerapan dan pengiriman yang jelas.
- Memilih cakupan idempotensi, status percobaan ulang, dan batas serah terima yang tahan lama (durable handoff).
- Mendesain isolasi penyewa, evolusi skema, dan bukti operasional.
Pertanyaan klarifikasi sebelum menjawab
- Berapa puncak event per detik dan ukuran payload yang harus didukung setiap penyewa?
- Apakah produsen diizinkan untuk mencoba ulang tanpa batas, dan apakah pengurutan diperlukan per sumber (source) atau subjek (subject)?
- Konsumen mana yang memerlukan pengiriman setidaknya-sekali, dan bisakah mereka melakukan deduplikasi berdasarkan sumber ditambah ID?
- Apakah skema terdaftar secara terpusat, dan berapa lama event mentah harus disimpan untuk pemutaran ulang (replay)?
Kerangka jawaban 30 detik
Saya akan menghentikan TLS di edge yang terotentikasi, memvalidasi amplop CloudEvents dan kuota penyewa, lalu menambahkan event mentah secara tahan lama sebelum memberikan pengakuan (acknowledgement). Antrean terpartisi menyebarkan (fan-out) ke konsumen menggunakan pengiriman setidaknya-sekali; (tenant, source, id) adalah kunci deduplikasi ketika produsen menjamin stabilitasnya. Pengakuan konsumen, jadwal percobaan ulang, dead letter, versi skema, dan batas per penyewa membuat kehilangan dan duplikasi terlihat jelas, bukan implisit.
Pembahasan mendalam langkah demi langkah
1. Menyerap dan memvalidasi
Menerima binding HTTP terstruktur atau biner, menerapkan batas ukuran dan tipe konten, serta memvalidasi atribut yang diperlukan seperti specversion, type, source, dan id. Mengautentikasi penyewa dan menolak amplop yang tidak valid sebelum melakukan pekerjaan yang tahan lama. Menyimpan byte dan header yang diterima secara tepat untuk audit dan pemutaran ulang.
2. Memilih batas ketahanan (durable boundary)
Menulis catatan event yang tidak dapat diubah (immutable) dan offset outbox atau log dalam satu operasi tahan lama sebelum mengembalikan status berhasil. Pengakuan hanya pada antrean berisiko kehilangan event jika penerbitan ke antrean tidak di-commit; desain yang hanya berbasis basis data dapat menjadi penghambat (bottleneck) pada fan-out bervolume tinggi. Nyatakan pertukaran (trade-off) antara latensi dan ketahanan.
3. Melakukan deduplikasi tanpa menyembunyikan percobaan ulang
Gunakan kunci (source, id) berlingkup penyewa dengan periode retensi yang mencakup percobaan ulang produsen. Simpan digest payload dan versi skema; kunci yang sama dengan byte berbeda adalah konflik yang memerlukan karantina. Pisahkan upaya pengiriman dari event logis agar percobaan ulang tetap dapat diobservasi.
4. Mengirim dan mencoba ulang
Konsumen menarik (pull) dari partisi atau menerima pengiriman yang didorong (push) dengan sewa (lease). Pengakuan yang berhasil akan memajukan percobaan; batas waktu dan kegagalan sementara menjadwalkan backoff eksponensial dengan jitter. Kegagalan permanen dipindahkan ke aliran dead-letter berlingkup penyewa dengan kontrol pemutaran ulang dan catatan audit.
5. Mengembangkan dan mengoperasikan
Validasi versi skema saat masuk (ingress), rutekan event yang tidak kompatibel ke karantina, dan dukung deklarasi kemampuan konsumen. Ukur event yang diterima, ditolak, duplikat, tertunda, dicoba ulang, masuk ke dead-letter, dan diputar ulang berdasarkan penyewa dan sumber. Terapkan kuota, enkripsi, retensi, dan kontrol akses tanpa mencatat rahasia atau payload tanpa batas ke log.
Contoh jawaban berkualitas tinggi
“Saya akan mengautentikasi setiap penyewa di edge, memvalidasi amplop CloudEvents, menerapkan batas ukuran dan kuota, serta menambahkan event dan header yang tepat secara tahan lama sebelum memberikan konfirmasi. Log terpartisi kemudian mengirimkan setidaknya sekali. Kunci deduplikasi adalah penyewa ditambah sumber ditambah ID ketika produsen menjamin stabilitas ID; digest yang berubah untuk kunci yang sama akan dikarantina. Konsumen mengakui upaya pengiriman, kegagalan sementara mundur dengan jitter, dan kegagalan permanen masuk ke aliran dead-letter yang dapat diputar ulang. Versi skema, metrik per penyewa, retensi, dan log audit membuat semantik pengiriman menjadi eksplisit.”
Kesalahan umum
- Memberikan pengakuan sebelum penambahan tahan lama → kerusakan sistem (crash) menghilangkan event → beri ack setelah batas tahan lama yang dipilih.
- Deduplikasi berdasarkan ID secara global → penyewa atau sumber dapat bertabrakan → batasi lingkup kunci dan verifikasi digest.
- Menjanjikan tepat satu kali (exactly-once) → percobaan ulang dan efek samping konsumen tetap memungkinkan → nyatakan setidaknya-sekali dan wajibkan konsumen yang idempoten.
- Menghilangkan skema yang tidak kompatibel → debugging dan pemutaran ulang menjadi mustahil → karantina dengan bukti berversi.
Pertanyaan lanjutan dan jawaban
Bisakah gateway menjamin pengurutan?
Hanya dalam lingkup yang ditentukan, seperti partisi sumber dan subjek. Pertahankan metadata urutan, rutekan kunci yang sama ke satu partisi, dan dokumentasikan bahwa percobaan ulang atau konsumen paralel dapat menunda event berikutnya.
Bagaimana jika produsen menggunakan kembali ID untuk payload yang berbeda?
Bandingkan digest yang disimpan dan tolak atau karantina konflik tersebut. Jangan pernah menimpa event pertama secara diam-diam; beri tahu produsen karena kontrak deduplikasi telah dilanggar.
Bagaimana Anda mendukung pemutaran ulang khusus penyewa?
Simpan catatan event yang tidak dapat diubah dengan token pemutaran ulang yang terikat otorisasi, ID upaya baru, batas laju (rate limits), dan jejak audit. Pemutaran ulang harus lolos pemeriksaan skema dan deduplikasi serta tidak boleh melewati isolasi penyewa.