请问下这种业务如何设计解耦？

加多一层， 把 服务 和 快递 作为单独的一个提供服务或需要服务的应用，由这一层提供中介的服务。

这样的好处是， 服务 和 快递， 只做自己的事。比如 快递 不用做推送给服务A之类逻辑，而是告诉加多的这层。 至于要怎么处理，正是你现在要写的逻辑。

如果 快递 崩了，不会影响到服务，因为解耦了，就算中间层崩了，不会影响到 服务 或 快递正常业务，它一个中介的，没有直接 侵入 服务 或 快递的领域， 修复之后，数据都还在（指快递数据 或者服务者相关的数据）。

一般就是用队列，快递签收事件写入队列，要消费的服务自己去拉数据消费

a，b服务都要调用快递c查询接口，是否已签收的回调，快递信息更新，如果有个快递服务中间表和各类服务和快递关联起来，可以使用队列或者在事件回调中直接查询中间表关联的服务用户通知和更新对应数据