Temu Duga Reka Bentuk Sistem: Mereka Bentuk Platform Penghantaran Webhook yang Boleh Dipercayai

Masalah dan Skop

Platform SaaS mengeluarkan peristiwa seperti invoice.paid, order.shipped, dan user.disabled. Pelanggan mendaftarkan titik akhir HTTPS dan melanggan setiap titik akhir kepada jenis peristiwa yang dipilih. Reka bentuk platform keluar daripada peristiwa perniagaan yang telah dikomit sehingga respons HTTP pelanggan. Pentadbiran titik akhir, sejarah penghantaran, pemutaran rahsia (secret rotation), dan main semula manual berada dalam skop. Pemprosesan dalaman pelanggan selepas ia mengakui permintaan adalah di luar kawalan platform.

Gunakan andaian temu duga ini:

• Produk mencipta 50 juta peristiwa perniagaan setiap hari. Setiap peristiwa sepadan dengan empat titik akhir secara purata, menghasilkan 200 juta penghantaran logik setiap hari.
• Beban purata adalah kira-kira 579 peristiwa dan 2,315 penghantaran baharu sesaat. Puncak sepuluh kali ganda adalah kira-kira 5,787 peristiwa dan 23,148 penghantaran baharu sesaat.
• Jika percubaan semula menambah 10% lagi percubaan, laluan penghantaran puncak harus menampung kira-kira 25,463 percubaan sesaat.
• Di bawah puncak normal, 99% penghantaran baharu yang layak harus memulakan percubaan pertama mereka dalam masa 10 saat. Percubaan semula mempunyai tarikh akhir 24 jam, dan sejarah penghantaran kekal boleh ditanya selama 30 hari.
• Dengan muatan peristiwa tidak boleh ubah 1.5 KB, 300 bait metadata penghantaran, 250 bait setiap percubaan, dan 1.1 percubaan setiap penghantaran, storan logik adalah kira-kira 190 GB sehari atau 5.7 TB untuk 30 hari. Ini tidak termasuk indeks, replika, pemampatan, dan overhed storan objek.

Ini adalah input penentuan saiz, bukan penanda aras industri. Pengebilan, transformasi muatan sewenang-wenangnya, webhook masuk, dan reka bentuk aplikasi pelanggan berada di luar skop. Kontrak utamanya ialah penghantaran sekurang-kurangnya sekali: penduaan dan ketibaan tidak mengikut urutan adalah mungkin, manakala kehilangan senyap di dalam sempadan pengekalan dan percubaan semula yang dijanjikan mesti dapat dikesan dan dipulihkan.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah sama ada calon mentakrifkan pengecam dan jaminan dengan tepat. Satu event_id mewakili fakta perniagaan yang dikomit. Satu delivery_id mewakili peristiwa tersebut yang dihantar ke satu titik akhir dan kekal stabil merentasi percubaan semula automatik dan penghantaran semula manual. Kekangan unik pada (event_id, endpoint_id) menghalang main semula fan-out daripada mencipta penghantaran logik kedua. Ia tidak menghalang permintaan HTTP yang sama daripada sampai ke pelanggan dua kali apabila pekerja (worker) kehilangan respons.

Isyarat kedua ialah sempadan transaksi. Menerbitkan terus selepas komit pangkalan data perniagaan mewujudkan jurang dwi-tulis (dual-write gap): transaksi mungkin dikomit dan proses mungkin ranap sebelum penerbitan. Outbox transaksi, penstriman penangkapan data perubahan (CDC), atau sumber peristiwa tahan lasak yang setara menutup jurang tersebut. Fan-out kemudiannya menzahirkan (materializes) keadaan penghantaran sebelum dihantar, supaya sistem dapat menjawab titik akhir mana yang dipilih, percubaan mana yang dijalankan, dan apa yang masih tertunggak.

Isyarat ketiga ialah pengasingan kegagalan. Titik akhir yang perlahan tidak boleh menduduki setiap sambungan. Penyewa dengan ribuan destinasi yang gagal tidak boleh menggunakan belanjawan percubaan semula bagi penyewa yang sihat. Pembahagian baris gilir sahaja tidak memberikan keadilan; reka bentuk memerlukan keserentakan terhad bagi setiap titik akhir, kuota penyewa, penjadualan percubaan semula, dan keadaan pemutus litar (circuit-breaker) atau jeda.

Isyarat keempat ialah keselamatan merentasi dua arah. Penerima memerlukan tandatangan HMAC ke atas bait yang tepat serta metadata penghantaran yang disahkan. Pengirim juga mesti menganggap URL yang dikawal oleh pelanggan sebagai permukaan SSRF, menyekat skema dan destinasi, mengesahkan semula hasil DNS, mengekang pengalihan (redirects), dan mengasingkan egress. Jawapan yang kukuh menghubungkan kawalan ini kepada pemutaran rahsia, perlindungan main semula, kebolehhitungan (auditability), dan tindak balas insiden.

Soalan untuk Dijelaskan Sebelum Menjawab

• Apakah itu kejayaan? Reka bentuk ini menganggap sebarang respons 2xx sebagai pengakuan titik akhir. 3xx, tamat masa, ralat sambungan, 408, 429, atau 5xx bukanlah kejayaan. Pengakuan tidak membuktikan bahawa pemprosesan perniagaan kemudian oleh pelanggan telah berjaya.
• Peristiwa dan versi muatan mana yang dijanjikan? Setiap jenis peristiwa memerlukan skema dan dasar pemversian yang didokumentasikan. Percubaan semula menghantar bait muatan tidak boleh ubah yang sama; ia tidak boleh membina semula peristiwa lama daripada keadaan pangkalan data semasa.
• Apakah susunan yang diperlukan? Penghantaran lalai adalah tidak tersusun. Jika pelanggan memerlukan susunan untuk satu agregat, sertakan object_id dan object_version yang meningkat secara monotonik, atau tawarkan kunci susunan pilihan sertai (opt-in) yang menerima sekatan kepala baris (head-of-line blocking). Susunan global tidak diperlukan mahupun mampu ditampung.
• Berapa lama platform boleh mencuba semula dan memainkan semula? Di sini, percubaan semula automatik berhenti selepas 24 jam dan log kekal selama 30 hari. Main semula selepas tetingkap automatik menggunakan identiti peristiwa dan penghantaran asal tetapi mencipta rekod percubaan baharu.
• Bolehkah titik akhir menghala ke mana-mana sahaja? Produk hanya menerima titik akhir HTTPS awam. Destinasi peribadi, loopback, link-local, multicast, dikhaskan, dan metadata awan ditolak untuk IPv4 dan IPv6.
• Apakah data yang boleh meninggalkan platform? Kebenaran langganan dan pengecilan muatan adalah sebahagian daripada fan-out. Medan sensitif ditinggalkan atau diwakili oleh rujukan sumber apabila integrasi boleh mengambilnya melalui API yang disahkan.

Jawapan 30 Saat

“Saya akan mengkomit setiap peristiwa perniagaan melalui outbox, menerbitkannya ke log peristiwa tahan lasak, dan meminta perkhidmatan fan-out menyelesaikan langganan aktif. Ia mencipta satu baris penghantaran bagi setiap (event_id, endpoint_id) sebelum meletakkan kerja pada baris gilir. Pekerja menuntut percubaan dengan pajakan (leases), mengenakan had bagi setiap titik akhir dan setiap penyewa, menandatangani bait tidak boleh ubah bersama-sama ID penghantaran yang stabil dan cap masa percubaan semasa, serta menghantar melalui HTTPS. 2xx melengkapkan penghantaran; kegagalan yang boleh dicuba semula menggunakan pengunduran eksponen (exponential backoff) dengan jitter penuh sehingga tarikh akhir 24 jam, manakala kegagalan kekal dihentikan. Oleh kerana tamat masa selepas penghantaran adalah kabur, kontraknya adalah sekurang-kurangnya sekali dan pelanggan menyahduplikasi menggunakan ID penghantaran. Saya akan menambah pemutaran rahsia yang ditandatangani, pengesahan URL selamat-SSRF, log penghantaran dan main semula, pemutus litar titik akhir, dan penyesuaian (reconciliation) yang mengesan jurang outbox, fan-out, atau baris gilir.”

Perbincangan Mendalam Langkah demi Langkah

Mulakan pada penciptaan peristiwa. Dalam transaksi tempatan yang sama yang mengubah keadaan perniagaan, tulis baris outbox yang mengandungi event_id, penyewa, jenis, versi skema, identiti dan versi objek, masa kejadian, dan rujukan kepada bait muatan bersiri kanonikal. Geganti outbox (outbox relay) menerbitkan ke log tahan lasak yang dipisahkan. Geganti boleh menerbitkan dua kali, jadi pengguna hiliran menyahduplikasi menggunakan event_id. Jika data perniagaan merentasi sistem, pengeluar berwibawa memiliki peristiwa tersebut; perkhidmatan webhook tidak seharusnya membina semula fakta dengan meninjau (polling) jadual yang boleh berubah.

API satah kawalan (control-plane) boleh menjadi kecil dan eksplisit:

POST /v1/webhook-endpoints
PATCH /v1/webhook-endpoints/{endpoint_id}
POST /v1/webhook-endpoints/{endpoint_id}/rotate-secret
GET  /v1/webhook-deliveries?endpoint_id=&status=&cursor=
POST /v1/webhook-deliveries/{delivery_id}/replay

Penciptaan titik akhir mengesahkan penyewa, menerima URL HTTPS dan penapis jenis peristiwa, mengesahkan destinasi, dan mengembalikan rahsia menandatangani sekali sahaja. Penghantaran cabaran boleh membuktikan pemilikan, tetapi cabaran yang berjaya tidak menjadikan jawapan DNS masa hadapan selamat. Pemutaran rahsia memastikan versi semasa dan sebelumnya aktif semasa pertindihan terhad dan mendedahkan versi tandatangan mana yang digunakan. Mengemas kini URL mencipta versi konfigurasi yang boleh diaudit; ia tidak menulis semula percubaan sejarah secara senyap.

Gunakan empat rekod tahan lasak:

Endpoint(endpoint_id, tenant_id, url, status, event_types,
         current_secret_version, previous_secret_version, config_version)

Event(event_id, tenant_id, type, schema_version, object_id,
      object_version, occurred_at, payload_ref, payload_hash)

Delivery(delivery_id, event_id, endpoint_id, endpoint_config_version,
         status, attempt_count, next_attempt_at, expires_at, lease_version)

Attempt(attempt_id, delivery_id, attempt_number, started_at, finished_at,
        http_status, latency_ms, error_class, response_digest)

Perkhidmatan fan-out membaca peristiwa, memuatkan langganan aktif yang dibenarkan untuk penyewa dan jenis peristiwa tersebut, kemudian memasukkan baris penghantaran dalam kelompok terhad. Pangkalan data menguatkuasakan keunikan pada (event_id, endpoint_id). Hanya selepas baris wujud, ia memasukkan nilai delivery_id ke dalam baris gilir. Jika memasukkan ke dalam baris gilir gagal, pembersih (sweeper) mencari baris PENDING yang perlu diproses tanpa kerja baris gilir yang aktif. Jika proses fan-out ranap di pertengahan jalan, main semula mengulangi carian dan kekangan keunikan hanya mengisi baris yang hilang. Syot kilat (snapshot) langganan yang disimpan atau versi konfigurasi titik akhir menjadikan audit kemudian hari boleh dijelaskan.

Kerja baharu dan percubaan semula tidak seharusnya berkongsi satu FIFO tanpa had. Penjadual memilih baris yang perlu diproses ke dalam baldi masa, kemudian menggunakan keadilan penyewa berwajaran, baldi token titik akhir, dan keserentakan titik akhir terhad. Titik akhir yang sihat diteruskan sementara titik akhir yang perlahan mencapai had penerbangannya sendiri. Kegagalan berulang membuka litar dan memindahkan percubaan kemudian lebih jauh ke luar, tetapi penghantaran kekal kelihatan dan layak untuk percubaan prob. Kuota seluruh penyewa menghalang jutaan titik akhir yang teruk daripada memakan seluruh kumpulan pekerja (fleet). Kerja percubaan semula boleh meminjam kapasiti terbiar, tetapi tidak boleh menyebabkan usia penghantaran baharu tertua terlepas SLO-nya.

Pekerja menuntut penghantaran secara atomik dengan pajakan dan lease_version yang meningkat. Ia membaca bait muatan yang disimpan, mencipta cap masa percubaan, dan menandatangani rentetan kanonikal seperti delivery_id.timestamp.payload_bytes dengan HMAC-SHA256. Ia menghantar bait bertandatangan yang tepat dan pengepala yang mengandungi jenis peristiwa, ID penghantaran, masa kejadian peristiwa, masa percubaan, versi skema, dan versi tandatangan. Pengguna mengesahkan bait mentah menggunakan perbandingan masa malar (constant-time), menyemak toleransi cap masa, dan menyahduplikasi ID penghantaran yang stabil. Setiap percubaan semula mendapat cap masa percubaan dan tandatangan baharu sambil mengekalkan ID penghantaran dan bait peristiwa.

Dasar respons mestilah deterministik. Sebarang 2xx menandakan penghantaran SUCCEEDED. Jangan ikuti 3xx secara automatik. Anggap 408, 429, 5xx, set semula sambungan, dan tamat masa sebagai boleh dicuba semula, dan hormati Retry-After terhad pada 429 atau 503; kebanyakan respons 4xx lain adalah kekal untuk konfigurasi tersebut. Kegagalan TLS dan DNS mungkin bermula sebagai boleh dicuba semula tetapi membuka litar titik akhir dengan cepat. Gunakan pengunduran eksponen dengan jitter penuh, kelewatan maksimum, kiraan percubaan maksimum, dan tarikh akhir mutlak 24 jam. Tamat masa selepas permintaan meninggalkan pekerja ialah hasil yang tidak diketahui: mencuba semula boleh menduplikasi pemprosesan pelanggan, jadi platform tidak boleh mengiklankan tepat sekali (exactly once).

Main semula manual mencipta satu lagi Attempt untuk Delivery logik yang sama; ia tidak mencipta peristiwa perniagaan baharu. Pengendali melihat muatan tidak boleh ubah asal, konfigurasi titik akhir yang digunakan, semua kelas respons, dan sama ada percubaan semula automatik masih aktif. Kebenaran disemak semula sebelum main semula, dan rahsia aktif semasa titik akhir boleh menandatangani percubaan baharu. Jika produk sebaliknya menjanjikan pengesahan sejarah bait demi bait, ia mesti mengekalkan kunci sejarah yang diperlukan di bawah dasar pengekalan kunci yang ditakrifkan.

URL yang dibekalkan oleh pelanggan memerlukan sempadan egress yang khusus. Huraikan (parse) dengan satu pelaksanaan URL yang diuji dengan baik, benarkan HTTPS dan port yang diluluskan, tolak kelayakan dalam URL, selesaikan semua jawapan A dan AAAA, dan sekat julat peribadi, loopback, link-local, dikhaskan, multicast, dan metadata. Sahkan sekali lagi pada masa sambungan atau semat (pin) alamat yang disahkan untuk mengurangkan jurang pengikatan semula DNS (DNS-rebinding) dan masa-pemeriksaan/masa-penggunaan (TOCTOU). Lumpuhkan pengalihan, atau jalankan semula dasar lengkap untuk setiap lompatan tanpa memajukan rahsia. Letakkan pekerja dalam rangkaian egress yang tidak dapat mencapai satah kawalan atau perkhidmatan dalaman, dan hadkan masa sambungan, jumlah masa permintaan, bait respons, dan penyahmampatan.

Kapasiti mengikut fan-out, bukan hanya kiraan peristiwa. Lima puluh juta peristiwa didarabkan dengan empat langganan menghasilkan 200 juta penghantaran setiap hari. Pada 1.1 percubaan setiap satu, sejarah percubaan ialah 220 juta baris sehari. Andaian saiz mentah memberikan 50M × 1.5 KB = 75 GB, 200M × 300 B = 60 GB, dan 220M × 250 B = 55 GB, berjumlah kira-kira 190 GB sehari. Pastikan indeks keadaan tertunggak semasa kekal kecil, pisahkan sejarah mengikut masa dan hash penyewa, dan arkibkan muatan tidak boleh ubah serta percubaan lama ke storan yang lebih murah. Ukur kelengahan peristiwa-ke-fan-out, usia tertua baharu dan percubaan semula, kependaman percubaan pertama, kejayaan mengikut titik akhir dan kelas status, amplifikasi percubaan semula, keadaan litar, pendikit penyewa, dan hasil main semula.

Akhir sekali, selaraskan setiap sempadan tahan lasak. Bandingkan baris outbox yang dikomit dengan ID peristiwa yang diterbitkan, peristiwa dengan syot kilat langganan dan kiraan penghantaran yang dijangkakan, baris penghantaran tertunggak dengan pajakan penjadual, dan kiraan penamat dengan sejarah percubaan. Suntikan kegagalan (fault-injection) harus meranapkan geganti selepas penerbitan, meranapkan fan-out di separuh jalan, menduplikasi mesej baris gilir, mematikan pekerja selepas titik akhir jauh memproses POST tetapi sebelum penulisan kejayaan tempatan, mengembalikan respons 429 yang disegerakkan, dan membuatkan titik akhir satu penyewa tergantung. Penerimaan dinyatakan sebagai kiraan tahan lasak, usia baris gilir terhad, pemulihan adil, dan penduaan yang boleh dijelaskan—bukan sekadar permintaan demo yang berjaya.

Contoh Jawapan yang Kukuh

“Saya akan memberikan setiap fakta perniagaan yang dikomit satu event_id tidak boleh ubah, dan setiap pasangan peristiwa-titik akhir satu delivery_id yang stabil. Pengeluar menulis peristiwa ke outbox dalam transaksi perniagaannya. Geganti menerbitkan ke log tahan lasak, dan fan-out menzahirkan penghantaran di bawah kekangan unik (event_id, endpoint_id) sebelum membariskannya. Itu membolehkan main semula membaiki kerja yang hilang tanpa mencipta penghantaran logik kedua.

Pada tahap puncak yang dinyatakan, fan-out mencipta kira-kira 23,148 penghantaran baharu sesaat dan laluan penghantaran merancang untuk kira-kira 25,463 percubaan sesaat termasuk percubaan semula. Penjadual memisahkan kerja baharu dan percubaan semula, menggunakan keadilan penyewa berwajaran, keserentakan bagi setiap titik akhir dan baldi token, kemudian membiarkan pekerja menuntut percubaan dengan pajakan berversi. Oleh itu, seorang pelanggan yang perlahan hanya menggunakan peruntukannya sendiri. Kegagalan berulang membuka litar titik akhir sementara prob dan tarikh akhir percubaan semula 24 jam kekal kelihatan.

Setiap percubaan menandatangani delivery_id, cap masa percubaan, dan bait muatan tidak boleh ubah yang tepat dengan HMAC-SHA256. Pelanggan menyemak tandatangan dengan perbandingan masa malar, menolak cap masa lapuk, dan menyahduplikasi ID penghantaran yang stabil. 2xx berjaya. 408, 429, 5xx, ralat rangkaian, dan tamat masa dicuba semula dengan pengunduran eksponen dan jitter penuh; kebanyakan respons 4xx lain dihentikan. Pekerja boleh ranap selepas pelanggan memproses permintaan tetapi sebelum merekodkan kejayaan, jadi saya menjanjikan sekurang-kurangnya sekali dan mendokumentasikan bahawa pengguna mesti idempoten.

Satah kawalan menyediakan pengurusan titik akhir dan langganan, pemutaran rahsia pertindihan terhad, log penghantaran, dan main semula. URL titik akhir melepasi kawalan HTTPS, julat IP, pengikatan semula DNS, pengalihan, tamat masa, dan saiz respons di dalam rangkaian egress yang diasingkan. Saya akan membuktikan reka bentuk ini dengan menyelaraskan setiap sempadan tahan lasak dan menyuntik penerbitan pendua, fan-out separa, pengakuan yang hilang, respons 429 secara besar-besaran, dan penyewa yang penuh dengan titik akhir tergantung. Kriteria lulus adalah SLO percubaan pertama, tiada jurang penghantaran yang tidak dapat dijelaskan, amplifikasi percubaan semula terhad, dan pemulihan yang adil untuk penyewa yang sihat.”

Kesilapan Biasa

• Menerbitkan selepas mengkomit data perniagaan → kerosakan antara dua operasi menyebabkan peristiwa webhook hilang → tulis outbox transaksi atau gunakan strim perubahan tahan lasak yang setara.
• Mencipta ID penghantaran baharu untuk setiap percubaan semula → penerima tidak dapat menyahduplikasi satu penghantaran logik → kekalkan delivery_id stabil dan cipta rekod percubaan yang berasingan.
• Menjanjikan penghantaran HTTP tepat sekali (exactly-once) → respons yang hilang selepas pemprosesan jauh menyebabkan pengirim tidak dapat mengetahui hasilnya → tawarkan penghantaran sekurang-kurangnya sekali dan perlukan pengendalian pengguna yang idempoten.
• Membina semula muatan semasa percubaan semula → keadaan pangkalan data semasa mengubah peristiwa sejarah dan membatalkan tandatangan lama → simpan bait peristiwa tidak boleh ubah kanonikal dan versi skemanya.
• Menggunakan satu FIFO untuk setiap titik akhir → destinasi perlahan menduduki sambungan dan melengahkan pelanggan yang sihat → hadkan kerja bagi setiap titik akhir dan jadualkan dengan keadilan penyewa.
• Mencuba semula setiap bukan-2xx serta-merta → kegagalan kekal membazirkan kapasiti dan percubaan semula yang disegerakkan menguatkan insiden → kelaskan ralat dan gunakan pengunduran eksponen dengan jitter penuh dan tarikh akhir.
• Mengikuti pengalihan daripada URL pelanggan → URL awam boleh mengalihkan pekerja ke perkhidmatan dalaman → lumpuhkan pengalihan atau sahkan semula setiap lompatan sepenuhnya dalam egress yang diasingkan.
• Menandatangani JSON yang dihuraikan → penyirikan semula mengubah bait dan menyebabkan tandatangan yang sah gagal → tandatangani dan sahkan badan mentah yang tepat ditambah metadata ID dan cap masa yang disahkan.
• Menganggap main semula papan pemuka sebagai peristiwa baharu → pelanggan hiliran mungkin menggunakan fakta perniagaan dua kali di bawah identiti baharu → mainkan semula penghantaran sedia ada dan rekodkan percubaan baharu.

Soalan Susulan dan Jawapan

Susulan 1: Mengapakah platform tidak dapat menjamin penghantaran tepat sekali?

Katakan titik akhir mengkomit kerjanya dan mengembalikan 200, tetapi sambungan ditutup sebelum pekerja membaca respons. Mencuba semula boleh mengulangi kesan sampingan pelanggan; tidak mencuba semula mungkin kehilangan peristiwa yang tidak pernah sampai. Pengirim tidak mempunyai transaksi atomik dengan pelayan pelanggan sewenang-wenangnya. ID penghantaran yang stabil, keidempotenan bahagian penerima, dan penyesuaian menjadikan penghantaran sekurang-kurangnya sekali dapat diuruskan, tetapi ia tidak mengubah dua pangkalan data dan rangkaian menjadi satu komit tepat sekali.

Susulan 2: Bagaimanakah anda menghalang satu titik akhir yang rosak daripada melengahkan semua orang lain?

Beri setiap titik akhir had dalam penerbangan (in-flight limit) yang kecil dan baldi token, kemudian jadualkan merentasi penyewa dengan keadilan berwajaran. Tamat masa melepaskan pajakan dan menjadualkan percubaan semula yang ditangguhkan dan bukannya tidur di dalam pekerja. Kegagalan berturut-turut membuka litar, jadi hanya prob terkawal yang berjalan sementara titik akhir yang sihat menggunakan kumpulan pekerja. Jejaki kedua-dua amplifikasi percubaan semula titik akhir dan penyewa; penyerang dengan banyak titik akhir mesti tetap berada dalam belanjawan seluruh penyewa.

Susulan 3: Apakah jaminan susunan yang akan anda tawarkan?

Lalai adalah tiada susunan penghantaran. Sertakan occurred_at, object_id, dan object_version monotonik supaya pengguna boleh membuang kemas kini lapuk atau mengambil keadaan semasa. Jika peringkat berbayar memerlukan susunan untuk satu objek, bahagikan langganan tersebut mengikut kunci susunan dan benarkan hanya satu jujukan aktif bagi setiap kunci. Item terdahulu yang gagal kemudiannya menyekat item kemudian pada kunci tersebut, jadi produk mesti mendedahkan pertukaran kependaman dan ketersediaan daripada mendakwa susunan global.

Susulan 4: Apakah yang berlaku semasa pemutaran rahsia menandatangani?

Cipta versi baharu, kekalkan versi sebelumnya untuk pertindihan terhad, dan kenal pasti versi yang diterima dalam pengepala atau dokumentasi. Semasa pertindihan, sama ada sertakan tandatangan daripada kedua-dua kunci atau biarkan pengguna mencuba kedua-duanya dengan selamat. Percubaan baharu menggunakan kunci aktif, manakala bait muatan tidak boleh ubah dan ID penghantaran kekal tidak berubah. Audit pelaku, masa, versi konfigurasi titik akhir, dan persaraan akhir. Kunci yang terjejas mungkin memerlukan persaraan segera dan panduan main semula yang kelihatan kepada pelanggan dan bukannya pertindihan.

Susulan 5: Bagaimanakah anda pulih selepas fan-out hanya diselesaikan sebahagiannya?

Mainkan semula peristiwa tahan lasak melalui fan-out. Kekangan unik (event_id, endpoint_id) menjadikan pemasukan yang telah selesai sebagai no-op dan hanya mencipta penghantaran yang hilang. Penyesuaian membandingkan syot kilat langganan atau versi konfigurasi yang disimpan bagi peristiwa tersebut dengan baris yang dizahirkan. Jika semantik langganan menyatakan "konfigurasi pada masa peristiwa", kekalkan syot kilat tersebut; menggunakan langganan hari ini semasa pembaikan boleh menghantar peristiwa ke destinasi yang tidak berhak menerimanya semasa peristiwa itu berlaku.

Susulan 6: Patutkah main semula manual menetapkan semula tarikh akhir 24 jam?

Percubaan semula automatik dan main semula pengendali ialah kontrak yang berasingan. Kerja automatik berhenti pada tarikh akhir asal. Main semula dalam tetingkap sejarah 30 hari mencipta percubaan baharu hanya selepas pemeriksaan kebenaran dan keadaan titik akhir, dan UI menandakannya dengan jelas sebagai manual. Ia tidak seharusnya mengaktifkan semula jadual automatik secara senyap. Untuk peristiwa keselamatan atau pemadaman, dasar mungkin melarang main semula selepas tarikh akhir perniagaan yang lebih pendek walaupun log kekal kelihatan.