我估計有不少讀者都在蹲前兩天美團瓜的后續，現在它來了。

如果你還不了解前因后果，可以先看下我前天寫的這篇《》。

簡單說，就是我在美團外賣上連續下單兩家不同門店的 KFC 然后被統一拒單。

看了這個現象后，不少讀者留言說了自己的猜測，那真實的后臺邏輯到底發生了什么呢？

問題出現后，美團外賣不同部門的同學都聯系到了我，有產品、有研發、有業務，都試圖通過我去還原問題原因。

我也把詳細的訂單情況截圖發給他們看了，其實當天晚上就有了反饋。

要理解這個現象背后的邏輯，我們得先了解一下美團外賣系統的構成，這里我只說三個大部分。

一個是美團自己的系統，一個是商家自研的系統，還有一個就是用戶端的系統。

我們使用美團外賣 App 下單，前端就是用戶系統，訂單流轉到美團后臺的訂單交易系統，這里面會經過一系列的復雜處理。

此時，如果商家使用的是美團提供的接單后臺，那實際上也是美團內部系統。

可還有一類，就是商家自研系統。

比如我下單的 KFC，他們就有自研系統，如果你用過 KFC 自家的 App 下單，對接的其實就是他們自己的系統。

包括你在抖音或者美團買的那種套餐券，最后也會對接到他們自研系統上走統一流程。

整個流程，如圖所示。

如果是商家自研系統接單，那就涉及到美團交易系統和商家自研系統之間的數據和邏輯對接，二者是一個請求和響應過程。

說白了，就是美團系統給商家自研系統發消息，商家系統自己解析并處理，然后將結果返回給美團系統。

這個過程，跟所有 API 調用流程是一樣的。

在正常情況下，這個流程是不會出現什么問題的。但是，那天恰恰有一個非正常情況。

我下單的那天是 7 月 5 號，而那一天美團外賣出現大爆單情況，直接把服務器干崩了，還上了熱搜。

在流量突然爆發的情況下，美團的交易系統出現計算結算金額異常的情況，導致這個數據不能及時下傳到 KFC 的自研系統。

然而，KFC 自研系統在邏輯處理上需要接收到這個預計收入的結算金額才能正常下單，否則就會做拒單處理。

因此，這也就解釋了為什么我在兩家不同的 KFC 門店下單都遇到被拒單情況的原因了。

據我了解，KFC 的自研系統對于是否接收到預計收入的結算金額這個數據是不影響結算的，嚴格來說屬于業務邏輯上的 bug。

作為處理方案，一方面是美團自己擴容服務器，以此來應對大流量的挑戰。另一方面是商家自研系統取消冗余邏輯，確保業務流程順利流轉。

所以，這個瓜得兩吃，兩邊都有各自的問題。

不過美團外賣的產品在提示文案上有點甩鍋的意思，這個感覺就是告知用戶訂單是被商家取消的。

而實際上，如果美團的服務器不出問題，商家肯定是能正常出單的，這也解釋了為什么我在淘寶餓了么能正常下單的原因。

可巧合就在于，美團服務器因為流量太大導致異常的同時觸發了 KFC 自研 系統的這個邏輯判斷，所以最終返回拒單結果。

我看之前文章留言區有一種猜測，說是 KFC 覺得美團來的單子提成太高收入低，所以統一都拒了。

這種可能性放在小商家那有可能，不過放在 KFC 這種大型連鎖門店的可能性就很低。

你想啊，KFC 這種總部強監管模式的連鎖企業，不太可能允許門店做這種影響口碑的事。

而且，KFC 的產能并不是跟不上需求，所以他們沒有必要通過選單的模式來消化產能。

理解了邏輯，我們才能更好洞察現象。

猜測只是感覺上的合理，分析才是邏輯上的成立。

作為普通用戶，我們能感知到的就是訂單被取消，肯定是不爽的，白等 40 分鐘 吃不上飯的體驗顯然不好。

作為產品經理或者研發人員，我們雖然也能通過問題調查和邏輯分析找到問題的根源，但這往往是滯后的。

做產品的過程，每天就是這么如履薄冰。

················· 唐韌出品 ·················

安可時刻

我已經到大連了，會在這邊待一陣子。

這里溫度會比長沙低一點，不過太陽底下也熱，太陽下去后的早晚略微涼爽，至少不用 24 小時開空調。

這是我第一次來大連，聽說海腸撈飯還行，你們有啥推薦的可以留言區說說。

今年下半年的線下產品訓練營還在報名中，北京、上海、深圳、杭州、成都、廣州的同學都可以聯系我占座：tangren0517

關于訓練營，可能也就都辦最后一期了。