好奇McDonald's 的后端逻辑是哪个AI写的？这 Race Condition简直叹为观止。

今天早上起床想顺手薅个麦当劳和 Savory Caviar 联名的鱼子酱套装（McNugget Caviar），结果被麦当当的系统玩耍了。
作为一名日常搬砖的，我忍不住来地里吐槽一下这个很特别的 Workflow。
感觉是直接用“Please write us an event page that gives away McNugget Caviar on 2/10/2026 at 11 AM EST”的Prompt生成后就上线了。


复盘一下经过：

• QPS没做：到时间，页面直接原地崩溃。显然是没有做任何海量并发的防护。
• 刷新填表：多次刷新后，load了表单，填完收货地址，页面显示 "It's Almost Yours!"，让我邮件验证。
• 异步延迟：足足 13 分钟后才收到那封名为 "Ready to enjoy a perfect pairing?" 的验证邮件。
• 关键 Bug：点击邮件里的 "Confirm email" 按钮后，系统直接给我跳转到了 "You Just Missed It!" 页面。
  

槽点如下：

• Distributed System 的大忌：发了验证邮件居然不锁库存（Reserve Inventory）？合着这邮件发出来，只是为了让我们参与一个开始时间不定的“谁点的链接快”的二次竞速？
• Consistency 极差：既然已经在第一步拿到了我的地址和信息，后端就应该做一个短暂的 Hold。
• UX 灾难：让用户在期待中等待十几分钟，最后点开却是一场空。这异步处理逻辑简直是分布式架构的教科书级反面教材。
  

有人今天抢到了吗？感觉写这个程序的 AI 真的需要回炉重造，建议在System Prompt里面加上 System Design 101 再来写业务。


那么面试题来了，麦当劳高并发抢购系统中的“延迟验证”架构设计，当当当！


1. 题目背景 (Scenario)
我们要设计一个限量版商品（如“鱼子酱套装”）的抢购系统。为了防止 Bot（机器人）抢单，系统要求用户在提交地址信息后，必须通过邮件点击验证链接（Email Verification）才能最终完成订单。


已知限制（Candidate需要clarify）：
库存极少（例如 1,000 份），但并发请求极高（每秒 100k+ QPS）。
邮件服务有延迟：从系统发信到用户点击链接，中间存在 1 到 20 分钟的随机网络和操作延迟。


2. 问题描述 (Problem)
如果系统在发送验证邮件时不锁定库存，会导致用户在收到邮件并点击时，库存早已被其他用户抢光，造成极差的用户体验（"You Just Missed It"）。
请设计一个方案，既能利用邮件验证过滤 Bot，又能保证“收到验证邮件的用户”有极大概率能最终拿到商品。


3. 核心考点 (Key Evaluation Points)
A. 库存锁定策略 (Inventory Locking)
候选人是否提出“预扣库存”（Soft Reserve）的概念？
在发送邮件的瞬间，在 Redis 中预扣一个库存，并设置一个 TTL（过期时间，如 30 分钟）。
如果 TTL 内用户未验证，库存自动释放回池。


B. 分布式事务与一致性 (Consistency)
如何处理分布式环境下的数据一致性？
使用分布式锁（如 Redlock）还是 Lua 脚本来保证操作的原子性？
如何防止在数据库（DB）和缓存（Cache）之间出现数据不一致？


C. 应对海量并发 (High Concurrency)
如何防止第一步页面直接崩溃？
考察点：入队削峰（Message Queue）、限流（Rate Limiting）、静态资源 CDN 加速。


D. 验证逻辑优化
如何平衡“安全性”与“公平性”？
如果在第一步（填写地址）就锁库存，可能导致 Bot 占坑不验证。
进阶方案：引入“排队令牌池”。只有拿到令牌且通过初步风控的用户才能触发发信逻辑，发信即代表 100% 预留成功。

字里行间都是我被耍的怨念~~~
麦当劳高并发抢购系统中的“延迟验证”架构设计 -> 这个是Gemini同学写的面试题，我修改了一下。