用于重试出站 Webhook 的自动化清理作业，随着数据增长可能会意外变得资源密集。简单的夜间删除作业可能无法跟上增加的吞吐量。为此，应通过 cron 作业触发一个公共 HTTP 端点以启动清理任务。对于大规模删除操作，该端点应将工作委托给幂等队列作业，这些作业以有界批次处理数据。重试账本至关重要，它通过使用唯一批次键进行条件删除，确保重复的清理操作不会引发意外的破坏性操作。作业必须设计为安全地处理重复消息，将其视为无操作（no-ops）。这种幂等性至关重要，因为重试是正常现象，系统必须能够稳健地处理它们。一个 Node.js cron HTTP 端点可以通过快速发布带有幂等键的单个有界批次来防止重复工作。实际的删除操作由专用作业处理，而非 cron 作业本身，因为 cron 作业存在时间限制。队列作业应有意保持简单：处理一个有界批次，删除记录，并在事务成功后才确认完成。这种设计使得重试无害。建议实现死信队列（dead-letter queue）以处理持久性失败，从而提供检查并重驱动问题消息的途径。测试重启场景很重要，以确保幂等机制在各种故障条件下能正常工作。可观测性至关重要，需详细记录批次 ID、计数和状态。避免在队列消息中放置大量数据。对于复杂的多步骤清理流程，Temporal 或 Airflow 等工作流引擎更为合适。所述模式最适合更简单的单次遍历保留任务，且需要公共可访问的端点。操作循环包括触发、入队、认领、删除、记录和确认。定期监控关键指标（如未处理批次的年龄和死信队列深度）至关重要。在更改保留策略之前运行预演查询（dry-run query）可提供防止意外数据丢失的安全网。整个流程应足够简单，以便即使在非工作时间也能理解和进行管理。