美团的瓜，后续来了

我估计有不少读者都在蹲前两天美团瓜的后续，现在它来了。

如果你还不了解前因后果，可以先看下我前天写的这篇《》。

简单说，就是我在美团外卖上连续下单两家不同门店的 KFC 然后被统一拒单。

看了这个现象后，不少读者留言说了自己的猜测，那真实的后台逻辑到底发生了什么呢？

问题出现后，美团外卖不同部门的同学都联系到了我，有产品、有研发、有业务，都试图通过我去还原问题原因。

我也把详细的订单情况截图发给他们看了，其实当天晚上就有了反馈。

要理解这个现象背后的逻辑，我们得先了解一下美团外卖系统的构成，这里我只说三个大部分。

一个是美团自己的系统，一个是商家自研的系统，还有一个就是用户端的系统。

我们使用美团外卖 App 下单，前端就是用户系统，订单流转到美团后台的订单交易系统，这里面会经过一系列的复杂处理。

此时，如果商家使用的是美团提供的接单后台，那实际上也是美团内部系统。

可还有一类，就是商家自研系统。

比如我下单的 KFC，他们就有自研系统，如果你用过 KFC 自家的 App 下单，对接的其实就是他们自己的系统。

包括你在抖音或者美团买的那种套餐券，最后也会对接到他们自研系统上走统一流程。

整个流程，如图所示。

如果是商家自研系统接单，那就涉及到美团交易系统和商家自研系统之间的数据和逻辑对接，二者是一个请求和响应过程。

说白了，就是美团系统给商家自研系统发消息，商家系统自己解析并处理，然后将结果返回给美团系统。

这个过程，跟所有 API 调用流程是一样的。

在正常情况下，这个流程是不会出现什么问题的。但是，那天恰恰有一个非正常情况。

我下单的那天是 7 月 5 号，而那一天美团外卖出现大爆单情况，直接把服务器干崩了，还上了热搜。

在流量突然爆发的情况下，美团的交易系统出现计算结算金额异常的情况，导致这个数据不能及时下传到 KFC 的自研系统。

然而，KFC 自研系统在逻辑处理上需要接收到这个预计收入的结算金额才能正常下单，否则就会做拒单处理。

因此，这也就解释了为什么我在两家不同的 KFC 门店下单都遇到被拒单情况的原因了。

据我了解，KFC 的自研系统对于是否接收到预计收入的结算金额这个数据是不影响结算的，严格来说属于业务逻辑上的 bug。

作为处理方案，一方面是美团自己扩容服务器，以此来应对大流量的挑战。另一方面是商家自研系统取消冗余逻辑，确保业务流程顺利流转。

所以，这个瓜得两吃，两边都有各自的问题。

不过美团外卖的产品在提示文案上有点甩锅的意思，这个感觉就是告知用户订单是被商家取消的。

而实际上，如果美团的服务器不出问题，商家肯定是能正常出单的，这也解释了为什么我在淘宝饿了么能正常下单的原因。

可巧合就在于，美团服务器因为流量太大导致异常的同时触发了 KFC 自研 系统的这个逻辑判断，所以最终返回拒单结果。

我看之前文章留言区有一种猜测，说是 KFC 觉得美团来的单子提成太高收入低，所以统一都拒了。

这种可能性放在小商家那有可能，不过放在 KFC 这种大型连锁门店的可能性就很低。

你想啊，KFC 这种总部强监管模式的连锁企业，不太可能允许门店做这种影响口碑的事。

而且，KFC 的产能并不是跟不上需求，所以他们没有必要通过选单的模式来消化产能。

理解了逻辑，我们才能更好洞察现象。

猜测只是感觉上的合理，分析才是逻辑上的成立。

作为普通用户，我们能感知到的就是订单被取消，肯定是不爽的，白等 40 分钟 吃不上饭的体验显然不好。

作为产品经理或者研发人员，我们虽然也能通过问题调查和逻辑分析找到问题的根源，但这往往是滞后的。

做产品的过程，每天就是这么如履薄冰。

················· 唐韧出品 ·················

安可时刻

我已经到大连了，会在这边待一阵子。

这里温度会比长沙低一点，不过太阳底下也热，太阳下去后的早晚略微凉爽，至少不用 24 小时开空调。

这是我第一次来大连，听说海肠捞饭还行，你们有啥推荐的可以留言区说说。

今年下半年的线下产品训练营还在报名中，北京、上海、深圳、杭州、成都、广州的同学都可以联系我占座：tangren0517

关于训练营，可能也就都办最后一期了。