如何处理失败或显着延迟的Webhook？
我们有一个中间软件取决于另一个系统来执行付款请求。该第三方系统通常会在稍后从我们的末端执行付款请求并在处理后成功完成时发送网络钩。 有时他们失败或显着延迟发送Webhook， 没有重试机制。但是，他们在结束时具有状态查询API ，以了解付款请求的当前状态。
我们根据此Webhook更新我们的付款状态，这对我们的系统至关重要。现在，对于用例，我们找到了两种方法来处理此失败的Webhook
- 运行调度程序来满足失败的Webhook请求和使用其状态查询API
- 实施一个队列，在发生原始付款请求并使用超时事件的原始付款请求并进行火灾状态查询API时，将添加新条目。 SQS。
以上方面有自己的利弊。 是否还有其他方法可以处理此用例？ 如果否，两个中的哪一个是最好的选择。
We have a middleware that depends on another system to execute payment requests. This third-party system usually sends a webhook later when a payment request is performed from our end and successfully done at their end after processing. Sometimes they failed or significantly delayed sending webhook and there is no retry mechanism at their end. However, they have a status query API at their end to know the current status of the payment request.
We update our payment status based on this webhook and this is very vital for our system. Now for the use case, we have found two ways to handle this failed webhook
- Run a scheduler to cater failed webhook requests and check with their status query API
- Implement a Queue, where a new entry will be added to the queue when an original payment request took place and fire status query API Using Time-out events eg. SQS.
The above way around has its own pros and cons. Is there any other way around to handle this use case? If no, which one of two would be the best choice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一种选择是使用 temporal.io 实现您的业务逻辑。在Webhook上起作用以及对并行状态API进行轮询的代码非常简单。
One option is to use an orchestrator like temporal.io to implement your business logic. The code to act on the webhook as well as poll the status API in parallel would be pretty simple.