Wawancara System Design: Mendesain Platform Pengiriman Webhook yang Andal

Masalah dan Cakupan

Sebuah platform SaaS memancarkan event seperti invoice.paid, order.shipped, dan user.disabled. Pelanggan mendaftarkan HTTPS endpoints dan melanggan setiap endpoint ke tipe event yang dipilih. Rancang platform outbound mulai dari business event yang telah di-commit hingga HTTP response pelanggan. Administrasi endpoint, riwayat pengiriman, rotasi secret, dan replay manual termasuk dalam cakupan. Pemrosesan internal pelanggan setelah mengakui (acknowledge) permintaan berada di luar kendali platform.

Gunakan asumsi wawancara berikut:

• Produk menghasilkan 50 juta business events per hari. Setiap event cocok dengan rata-rata empat endpoint, menghasilkan 200 juta pengiriman logis per hari.
• Beban rata-rata adalah sekitar 579 events dan 2.315 pengiriman baru per detik. Lonjakan sepuluh kali lipat (peak) adalah sekitar 5.787 events dan 23.148 pengiriman baru per detik.
• Jika retries menambahkan 10% upaya lebih banyak, jalur pengiriman puncak harus mampu menangani sekitar 25.463 upaya per detik.
• Di bawah kondisi puncak normal, 99% dari pengiriman baru yang memenuhi syarat harus memulai upaya pertamanya dalam waktu 10 detik. Retries memiliki batas waktu 24 jam, dan riwayat pengiriman tetap dapat di-query selama 30 hari.
• Dengan payload event immutable 1,5 KB, metadata pengiriman 300 byte, 250 byte per upaya, dan 1,1 upaya per pengiriman, penyimpanan logis adalah sekitar 190 GB per hari atau 5,7 TB selama 30 hari. Ini tidak termasuk indeks, replika, kompresi, dan overhead object-store.

Ini adalah input penentuan ukuran (sizing inputs), bukan tolok ukur industri. Penagihan (billing), transformasi payload arbitrer, inbound webhooks, dan desain aplikasi pelanggan berada di luar cakupan. Kontrak utamanya adalah pengiriman at-least-once: duplikasi dan kedatangan di luar urutan (out-of-order) mungkin terjadi, sementara kehilangan data tanpa peringatan di dalam batas retensi dan retry yang dijanjikan harus dapat dideteksi dan dipulihkan.

Hal yang Dievaluasi Pewawancara

Sinyal pertama adalah apakah kandidat mendefinisikan pengidentifikasi dan jaminan secara tepat. Satu event_id mewakili fakta bisnis yang telah di-commit. Satu delivery_id mewakili event tersebut yang dikirim ke satu endpoint dan tetap stabil di seluruh retry otomatis dan pengiriman ulang manual. Unique constraint pada (event_id, endpoint_id) mencegah replay fan-out membuat pengiriman logis kedua. Ini tidak mencegah permintaan HTTP yang sama mencapai pelanggan dua kali ketika worker kehilangan respons.

Sinyal kedua adalah batasan transaksi (transaction boundary). Menerbitkan langsung setelah commit database bisnis menciptakan celah dual-write: transaksi mungkin telah di-commit dan proses mengalami crash sebelum penerbitan. Transactional outbox, change-data-capture stream, atau sumber event durable yang setara dapat menutup celah tersebut. Fan-out kemudian mematerialisasikan status pengiriman sebelum dispatch, sehingga sistem dapat menjawab endpoint mana yang dipilih, upaya mana yang berjalan, dan apa yang masih tertunda.

Sinyal ketiga adalah isolasi kegagalan. Endpoint yang lambat tidak boleh menghabiskan setiap koneksi. Tenant dengan ribuan tujuan yang gagal tidak boleh menghabiskan anggaran retry milik tenant yang sehat. Partisi antrean saja tidak memberikan keadilan; desain membutuhkan konkurensi per-endpoint yang dibatasi, kuota tenant, penjadwalan retry, dan circuit-breaker atau status jeda (pause).

Sinyal keempat adalah keamanan di dua arah. Penerima memerlukan tanda tangan HMAC atas byte persis ditambah metadata pengiriman yang diautentikasi. Pengirim juga harus memperlakukan URL yang dikontrol pelanggan sebagai celah SSRF, membatasi skema dan tujuan, memvalidasi ulang hasil DNS, membatasi redirect, dan mengisolasi egress. Jawaban yang kuat menghubungkan kontrol-kontrol ini dengan rotasi secret, perlindungan replay, auditabilitas, dan respons insiden.

Pertanyaan yang Perlu Diklarifikasi Sebelum Menjawab

• Apa yang dimaksud dengan keberhasilan? Desain ini memperlakukan respons 2xx apa pun sebagai pengakuan endpoint. Respons 3xx, timeout, kesalahan koneksi, 408, 429, atau 5xx bukanlah keberhasilan. Pengakuan tidak membuktikan bahwa pemrosesan bisnis pelanggan selanjutnya berhasil.
• Event dan versi payload mana yang dijanjikan? Setiap tipe event memerlukan skema dan kebijakan pembuatan versi yang terdokumentasi. Retries mengirimkan byte payload immutable yang sama; mereka tidak boleh merekonstruksi event lama dari status database saat ini.
• Urutan seperti apa yang diperlukan? Pengiriman default tidak berurutan (unordered). Jika pelanggan memerlukan urutan untuk satu agregat, sertakan object_id dan object_version yang meningkat secara monoton, atau tawarkan ordering key opt-in yang menerima head-of-line blocking. Urutan global tidak diperlukan maupun tidak terjangkau dari segi biaya.
• Berapa lama platform dapat melakukan retry dan replay? Di sini, retry otomatis berhenti setelah 24 jam dan log disimpan selama 30 hari. Replay setelah batas waktu otomatis menggunakan identitas event dan pengiriman asli tetapi membuat catatan upaya baru.
• Bisakah endpoint mengarah ke mana saja? Produk ini hanya menerima HTTPS endpoints publik. Tujuan privat, loopback, link-local, multicast, reserved, dan cloud-metadata ditolak untuk IPv4 dan IPv6.
• Data apa yang boleh meninggalkan platform? Otorisasi langganan dan minimisasi payload adalah bagian dari fan-out. Field sensitif dihilangkan atau diwakili oleh referensi sumber daya ketika integrasi dapat mengambilnya melalui API yang diautentikasi.

Jawaban 30 Detik

“Saya akan melakukan commit setiap business event melalui outbox, menerbitkannya ke log event yang tahan lama, dan menggunakan layanan fan-out untuk menyelesaikan langganan aktif. Layanan ini membuat satu baris pengiriman per (event_id, endpoint_id) sebelum menempatkan tugas ke dalam antrean. Workers mengklaim upaya dengan lease, menerapkan batas per-endpoint dan per-tenant, menandatangani byte immutable bersama dengan ID pengiriman yang stabil dan timestamp upaya saat ini, lalu mengirimkannya melalui HTTPS. Status 2xx menyelesaikan pengiriman; kegagalan yang dapat diulang (retryable) menggunakan exponential backoff dengan full jitter hingga batas waktu 24 jam, sementara kegagalan permanen dihentikan. Karena timeout setelah pengiriman bersifat ambigu, kontraknya adalah at-least-once dan pelanggan melakukan deduplikasi berdasarkan ID pengiriman. Saya akan menambahkan rotasi secret yang ditandatangani, validasi URL yang aman dari SSRF, log pengiriman dan replay, endpoint circuit breaker, serta rekonsiliasi yang mendeteksi celah outbox, fan-out, atau antrean.”

Pembahasan Mendalam Langkah Demi Langkah

Mulailah dari pembuatan event. Dalam transaksi lokal yang sama yang mengubah status bisnis, tulis baris outbox yang berisi event_id, tenant, tipe, versi skema, identitas dan versi objek, waktu terjadinya, dan referensi ke byte payload kanonikal yang diserialisasi. Relay outbox menerbitkan ke log terpartisi yang tahan lama. Relay dapat menerbitkan dua kali, sehingga konsumen downstream melakukan deduplikasi berdasarkan event_id. Jika data bisnis mencakup beberapa sistem, produsen otoritatif adalah pemilik event tersebut; layanan webhook tidak boleh merekonstruksi fakta dengan melakukan polling pada tabel yang mutable.

API control-plane dapat dibuat ringkas 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

Pembuatan endpoint mengautentikasi tenant, menerima URL HTTPS dan filter tipe event, memvalidasi tujuan, dan mengembalikan signing secret satu kali. Pengiriman challenge dapat membuktikan kepemilikan, tetapi challenge yang berhasil tidak membuat respons DNS di masa mendatang aman. Rotasi secret menjaga versi saat ini dan sebelumnya tetap aktif selama periode tumpang tindih (overlap) yang terbatas dan mengekspos versi tanda tangan mana yang digunakan. Memperbarui URL membuat versi konfigurasi yang dapat diaudit; tindakan ini tidak menulis ulang upaya historis secara diam-diam.

Gunakan empat catatan durable:

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)

Layanan fan-out membaca sebuah event, memuat langganan aktif yang diotorisasi untuk tenant dan tipe event tersebut, kemudian memasukkan baris pengiriman dalam batch terbatas. Database menerapkan keunikan pada (event_id, endpoint_id). Hanya setelah baris dibuat, layanan memasukkan nilai delivery_id ke dalam antrean. Jika proses antrean gagal, sweeper akan menemukan baris PENDING yang jatuh tempo tanpa pekerjaan antrean aktif. Jika proses fan-out mengalami crash di tengah jalan, replay akan mengulangi pencarian dan batasan keunikan hanya mengisi baris yang hilang. Snapshot langganan yang disimpan atau versi konfigurasi endpoint membuat audit di masa mendatang dapat dijelaskan.

Pekerjaan baru dan retry tidak boleh berbagi satu FIFO yang tak terbatas. Scheduler memilih baris yang jatuh tempo ke dalam bucket waktu, lalu menerapkan keadilan tenant berbobot (weighted tenant fairness), token bucket endpoint, dan konkurensi endpoint yang dibatasi. Endpoint yang sehat terus berjalan sementara endpoint yang lambat mencapai batas in-flight miliknya sendiri. Kegagalan berulang membuka sirkuit (open circuit) dan menggeser upaya selanjutnya ke jadwal yang lebih lama, tetapi pengiriman tetap terlihat dan memenuhi syarat untuk upaya probe. Kuota di seluruh tenant mencegah jutaan endpoint bermasalah menghabiskan kapasitas seluruh armada. Pekerjaan retry dapat meminjam kapasitas yang menganggur, tetapi tidak boleh membuat usia pengiriman baru tertua meleset dari SLO-nya.

Worker secara atomik mengklaim pengiriman dengan lease dan lease_version yang meningkat. Worker membaca byte payload yang disimpan, membuat timestamp upaya, dan menandatangani string kanonikal seperti delivery_id.timestamp.payload_bytes dengan HMAC-SHA256. Worker mengirimkan byte persis yang ditandatangani dan header yang berisi tipe event, ID pengiriman, waktu terjadinya event, waktu upaya, versi skema, dan versi tanda tangan. Konsumen memverifikasi byte mentah menggunakan perbandingan constant-time, memeriksa toleransi timestamp, dan melakukan deduplikasi pada ID pengiriman yang stabil. Setiap retry mendapatkan timestamp upaya dan tanda tangan baru sambil tetap mempertahankan ID pengiriman dan byte event.

Kebijakan respons harus deterministik. Kode 2xx apa pun menandai pengiriman sebagai SUCCEEDED. Jangan ikuti 3xx secara otomatis. Perlakukan 408, 429, 5xx, reset koneksi, dan timeout sebagai kondisi yang dapat dicoba ulang (retryable), dan patuhi Retry-After yang terbatas pada 429 atau 503; sebagian besar respons 4xx lainnya bersifat permanen untuk konfigurasi tersebut. Kegagalan TLS dan DNS mungkin dimulai sebagai retryable tetapi membuka sirkuit endpoint dengan cepat. Gunakan exponential backoff dengan full jitter, penundaan maksimum, jumlah upaya maksimum, dan batas waktu mutlak 24 jam. Timeout setelah permintaan meninggalkan worker adalah hasil yang tidak diketahui: mencoba ulang dapat menduplikasi pemrosesan pelanggan, sehingga platform tidak boleh menjanjikan exactly once.

Replay manual membuat Attempt lain untuk Delivery logis yang sama; tindakan ini tidak menghasilkan business event baru. Operator melihat payload immutable asli, konfigurasi endpoint yang digunakan, semua kelas respons, dan apakah retry otomatis masih aktif. Otorisasi diperiksa ulang sebelum replay, dan secret aktif endpoint saat ini dapat menandatangani upaya baru. Jika produk menjanjikan autentikasi historis byte-for-byte, platform harus mempertahankan kunci historis yang diperlukan di bawah kebijakan retensi kunci yang telah ditentukan.

URL yang disediakan pelanggan memerlukan batasan egress khusus. Parsing dengan satu implementasi URL yang teruji dengan baik, izinkan HTTPS dan port yang disetujui, tolak kredensial dalam URL, resolve semua jawaban A dan AAAA, serta blokir rentang privat, loopback, link-local, reserved, multicast, dan metadata. Validasi lagi pada saat koneksi atau sematkan (pin) alamat yang telah divalidasi untuk mengurangi celah DNS-rebinding dan time-of-check/time-of-use. Nonaktifkan redirect, atau jalankan kembali kebijakan lengkap untuk setiap hop tanpa meneruskan secret. Tempatkan worker di jaringan egress yang tidak dapat menjangkau control plane atau layanan internal, dan batasi waktu koneksi, total waktu permintaan, byte respons, serta dekompresi.

Kapasitas bergantung pada fan-out, bukan hanya jumlah event. Lima puluh juta event dikalikan empat langganan menghasilkan 200 juta pengiriman per hari. Pada 1,1 upaya masing-masing, riwayat upaya adalah 220 juta baris per hari. Asumsi ukuran mentah menghasilkan 50M × 1.5 KB = 75 GB, 200M × 300 B = 60 GB, dan 220M × 250 B = 55 GB, dengan total sekitar 190 GB per hari. Jaga agar indeks status jatuh tempo saat ini tetap kecil, partisi riwayat berdasarkan waktu dan hash tenant, serta arsipkan payload immutable dan upaya lama ke penyimpanan yang lebih murah. Ukur jeda event-to-fan-out, usia pengiriman baru dan retry tertua, latensi upaya pertama, keberhasilan berdasarkan endpoint dan kelas status, amplifikasi retry, status sirkuit, throttling tenant, dan hasil replay.

Terakhir, lakukan rekonsiliasi pada setiap batas durable. Bandingkan baris outbox yang di-commit dengan ID event yang diterbitkan, event dengan snapshot langganan dan jumlah pengiriman yang diharapkan, baris pengiriman jatuh tempo dengan lease scheduler, dan jumlah terminal dengan riwayat upaya. Fault-injection harus menguji crash pada relay setelah penerbitan, crash fan-out di tengah jalan, duplikasi pesan antrean, menghentikan worker setelah endpoint jarak jauh memproses POST tetapi sebelum penulisan status berhasil di lokal, mengembalikan respons 429 yang tersinkronisasi, dan membuat endpoint salah satu tenant hang. Penerimaan sistem dinyatakan sebagai jumlah yang tahan lama (durable counts), usia antrean yang terbatas, pemulihan yang adil, dan duplikasi yang dapat dijelaskan—bukan sekadar permintaan demo yang berhasil.

Contoh Jawaban yang Kuat

“Saya akan memberikan event_id yang immutable untuk setiap fakta bisnis yang telah di-commit, dan delivery_id yang stabil untuk setiap pasangan event-endpoint. Produsen menulis event ke outbox dalam transaksi bisnisnya. Relay menerbitkan ke log yang tahan lama, dan fan-out mematerialisasikan pengiriman di bawah batasan (event_id, endpoint_id) yang unik sebelum memasukkannya ke dalam antrean. Hal ini memungkinkan replay untuk memperbaiki pekerjaan yang hilang tanpa membuat pengiriman logis kedua.

Pada puncak beban yang disebutkan, fan-out menghasilkan sekitar 23.148 pengiriman baru per detik dan jalur dispatch merencanakan sekitar 25.463 upaya per detik termasuk retry. Scheduler memisahkan pekerjaan baru dan retry, menerapkan keadilan tenant berbobot, konkurensi per-endpoint dan token bucket, lalu membiarkan worker mengklaim upaya dengan lease berversi. Dengan demikian, satu pelanggan yang lambat hanya akan mengonsumsi alokasinya sendiri. Kegagalan berulang membuka sirkuit endpoint sementara probe dan batas waktu retry 24 jam tetap terlihat.

Setiap upaya menandatangani delivery_id, timestamp upaya, dan byte payload immutable yang persis menggunakan HMAC-SHA256. Pelanggan memeriksa tanda tangan dengan perbandingan constant-time, menolak timestamp yang basi, dan melakukan deduplikasi pada ID pengiriman yang stabil. Respons 2xx dianggap berhasil. Respons 408, 429, 5xx, kesalahan jaringan, dan timeout akan dicoba ulang dengan exponential backoff dan full jitter; sebagian besar respons 4xx lainnya dihentikan. Worker dapat mengalami crash setelah pelanggan memproses permintaan tetapi sebelum mencatat keberhasilan, jadi saya menjanjikan at-least-once dan mendokumentasikan bahwa konsumen harus idempoten.

Control plane menyediakan manajemen endpoint dan langganan, rotasi secret dengan tumpang tindih terbatas, log pengiriman, dan replay. URL endpoint melewati kontrol HTTPS, rentang IP, DNS-rebinding, redirect, timeout, dan ukuran respons di dalam jaringan egress yang terisolasi. Saya akan membuktikan desain ini dengan merekonsiliasi setiap batas durable dan menyuntikkan pengujian publikasi duplikat, fan-out parsial, kehilangan acknowledgment, respons 429 massal, dan tenant yang penuh dengan endpoint yang hang. Kriteria kelulusan adalah SLO upaya pertama, tidak ada celah pengiriman yang tidak dapat dijelaskan, amplifikasi retry yang terbatas, dan pemulihan yang adil untuk tenant yang sehat.”

Kesalahan Umum

• Menerbitkan setelah commit data bisnis → crash di antara dua operasi akan menghilangkan event webhook → tulis transactional outbox atau gunakan change stream durable yang setara.
• Membuat ID pengiriman baru untuk setiap retry → penerima tidak dapat melakukan deduplikasi pada satu pengiriman logis → pertahankan delivery_id tetap stabil dan buat catatan upaya terpisah.
• Menjanjikan pengiriman HTTP exactly-once → hilangnya respons setelah pemrosesan jarak jauh membuat pengirim tidak dapat mengetahui hasilnya → tawarkan pengiriman at-least-once dan wajibkan penanganan konsumen yang idempoten.
• Membangun kembali payload saat retry → status database saat ini mengubah event historis dan membatalkan tanda tangan lama → simpan byte event immutable kanonikal beserta versi skemanya.
• Menggunakan satu FIFO untuk setiap endpoint → tujuan yang lambat akan memonopoli koneksi dan menunda pelanggan yang sehat → batasi pekerjaan per-endpoint dan jadwalkan dengan keadilan tenant.
• Mencoba ulang setiap non-2xx secara langsung → kegagalan permanen membuang kapasitas dan retry yang tersinkronisasi memperparah insiden → klasifikasikan kesalahan dan gunakan exponential backoff dengan full jitter dan batas waktu.
• Mengikuti redirect dari URL pelanggan → URL publik dapat mengarahkan worker ke layanan internal → nonaktifkan redirect atau validasi ulang setiap hop sepenuhnya di dalam jaringan egress terisolasi.
• Menandatangani JSON yang telah di-parse → serialisasi ulang mengubah byte dan menyebabkan tanda tangan yang valid menjadi gagal → tandatangani dan verifikasi raw body yang persis ditambah metadata ID dan timestamp yang diautentikasi.
• Memperlakukan replay dashboard sebagai event baru → pelanggan downstream dapat menerapkan fakta bisnis dua kali di bawah identitas baru → putar ulang pengiriman yang ada dan catat sebagai upaya baru.

Pertanyaan Lanjutan dan Jawaban

Pertanyaan Lanjutan 1: Mengapa platform tidak dapat menjamin pengiriman exactly-once?

Misalkan endpoint melakukan commit pada pekerjaannya dan mengembalikan 200, tetapi koneksi terputus sebelum worker membaca respons tersebut. Mencoba ulang dapat mengulang efek samping pada pelanggan; tidak mencoba ulang dapat menghilangkan event yang sebenarnya tidak pernah sampai. Pengirim tidak memiliki transaksi atomik dengan server pelanggan arbitrer. ID pengiriman yang stabil, idempotensi di sisi penerima, dan rekonsiliasi membuat pengiriman at-least-once dapat dikelola, tetapi hal tersebut tidak mengubah dua database dan satu jaringan menjadi satu commit exactly-once.

Pertanyaan Lanjutan 2: Bagaimana cara mencegah satu endpoint yang rusak menunda pengiriman yang lain?

Beri setiap endpoint batas in-flight yang kecil dan token bucket, lalu jadwalkan di seluruh tenant dengan weighted fairness. Waktu tunggu (timeout) akan melepaskan lease dan menjadwalkan retry yang tertunda alih-alih membiarkan worker tidur (sleeping). Kegagalan berturut-turut akan membuka sirkuit, sehingga hanya probe terkontrol yang dijalankan sementara endpoint yang sehat tetap menggunakan armada worker. Lacak amplifikasi retry pada level endpoint maupun tenant; penyerang dengan banyak endpoint harus tetap dibatasi dalam anggaran tingkat tenant.

Pertanyaan Lanjutan 3: Jaminan pengurutan (ordering) apa yang akan Anda tawarkan?

Secara default tidak ada urutan pengiriman. Sertakan occurred_at, object_id, dan object_version monotonik sehingga konsumen dapat membuang pembaruan yang usang atau mengambil status terbaru. Jika tingkatan berbayar memerlukan pengurutan untuk satu objek, partisi langganan tersebut dengan ordering key dan hanya izinkan satu urutan aktif per kunci. Item sebelumnya yang gagal kemudian akan memblokir item berikutnya pada kunci tersebut, sehingga produk harus mengekspos konsekuensi (tradeoff) latensi dan ketersediaan daripada mengklaim urutan global.

Pertanyaan Lanjutan 4: Apa yang terjadi selama rotasi signing-secret?

Buat versi baru, pertahankan versi sebelumnya untuk masa tumpang tindih (overlap) yang terbatas, dan identifikasi versi yang diterima dalam header atau dokumentasi. Selama overlap, sertakan tanda tangan dari kedua kunci atau izinkan konsumen mencoba keduanya dengan aman. Upaya baru menggunakan kunci aktif, sementara byte payload immutable dan ID pengiriman tetap tidak berubah. Audit aktor, waktu, versi konfigurasi endpoint, dan penghentian akhir (retirement). Kunci yang disusupi mungkin memerlukan penghentian segera dan panduan replay yang terlihat oleh pelanggan alih-alih masa tumpang tindih.

Pertanyaan Lanjutan 5: Bagaimana cara memulihkan sistem setelah fan-out hanya selesai sebagian?

Putar ulang (replay) event durable melalui fan-out. Batasan (event_id, endpoint_id) unik menjadikan insert yang telah selesai sebagai no-op dan hanya membuat pengiriman yang hilang. Rekonsiliasi membandingkan snapshot langganan atau versi konfigurasi event yang disimpan dengan baris yang telah dimaterialisasi. Jika semantik langganan menyatakan “konfigurasi pada saat event terjadi,” pertahankan snapshot tersebut; menggunakan langganan saat ini selama proses perbaikan dapat mengirimkan event ke tujuan yang sebenarnya tidak berhak menerimanya saat event tersebut terjadi.

Pertanyaan Lanjutan 6: Haruskah replay manual mengatur ulang (reset) batas waktu 24 jam?

Retry otomatis dan replay operator adalah dua kontrak yang terpisah. Pekerjaan otomatis berhenti pada batas waktu aslinya. Replay dalam jendela riwayat 30 hari membuat upaya baru hanya setelah pemeriksaan otorisasi dan status endpoint berhasil, dan UI secara jelas menandainya sebagai manual. Ini tidak boleh mengaktifkan kembali jadwal otomatis secara diam-diam. Untuk event keamanan atau penghapusan, kebijakan dapat melarang replay setelah batas waktu bisnis yang lebih pendek meskipun log tetap terlihat.