服务之间的Webhook交换和警报路由

大多数集成在沉默中崩溃。一个服务触发了一个事件，接收方恰好在重启，没有人再试一次，您得知客户从未收到确认。我构建了使这种交换变得无聊和可预测的层：事件的接收点、其后的队列、通知的路由，以及一个回答“是否到达”的交付日志，而无需猜测。

工作从事件地图开始，而不是从代码开始。我们逐步了解您系统内部实际发生的事情，并挑选出值得反应的内容：新订单、支付失败、状态变化、已签署的文档。对于每一个，我记录下谁需要了解，多久，以及通过哪个渠道。未来一半的噪音在这一步消失，因为到目前为止，没有人问过一个事件是否值得发送消息。

然后是机制。没有签名检查的传入Webhook不被接受——否则任何人都可以向您发送事件，而伪造的事件的成本远高于错过的事件。被接受的事件进入队列，并在远端不可用时以逐渐增加的间隔重试。重复是正常的，因此每个事件都携带一个密钥，第二个相同密钥的副本不会改变任何东西。秘密和令牌保存在代码之外，永远不会到达日志。通知本身携带一个链接和一个数字，仅此而已：个人数据和文档内容不会放入公司一半的人都可以滚动查看的工作聊天中。

工作包括：
— 每个事件的地图及其原因；
— 带签名检查的Webhook接收和拒绝任何未签名的内容；
— 带重试的队列和可见的未处理事件积压；
— 防止重复处理同一事件；
— 按事件和接收者路由到邮件和团队消息；
— 使用简单语言的消息模板，没有原始负载转储；
— 可按事件搜索的交付日志，带手动重新发送；
— 当积压停止排出时发声的队列监控；
— 为团队提供的简短书面指南。