Architecture 规模/架构挑战

我最近采访了一家知名的、非常成功的公司，除了建筑部分，一切都进行得很顺利——我陷入困境，并给出了半个答案，但很明显，我在这方面没有足够的经验。很公平，但我认为，当规模如此之大时，如果你没有经历过，你就得不到经验，除非你能在其中一家公司找到一份工作。。无论如何从那以后我一直在琢磨这个问题，还没有想出我认为是一个好的解决方案。 大致是这样的：

我们想为客户做点好事。我们想要一个网站集 用户可以在上面输入他们的电子邮件地址，我们会给他们一个 一张免费X（汉堡、出租车、流媒体月、， 无论公司提供什么）。我们将捐出1000万个 凭证。我们预计由于需求量很大，我们将在几天内用完 5分钟。在任何情况下，我们都不得向单个用户（电子邮件地址）提供多张凭证，或提供的凭证数量超过分配的凭证数量，但 这不会是世界末日 稍微少一点

设计一个能够处理如此规模流量的系统架构

---

我真的很想听到一些意见和想法：）

我会尝试澄清额外的非功能性需求，比如它意味着什么稍微少一点？因为少5个条目或少5k条目是一个很大的区别。 是否对响应时间有具体要求？以及是否对凭证代码有任何要求

我想到的第一个解决方案是使用Lambda函数和电子邮件中的某种散列函数作为凭证代码。这样，我们可以确保同一封电子邮件始终收到相同的凭证代码，因此无需检查存储

---

然后，您可以配置lambda并行扩展不会超过（阈值），在提供令牌之前，您可以检查已注册电子邮件的数量，确保其小于或等于10M阈值。其中threshold是并发函数的数量。

稍微少一点，比如说。。。100? 也许我应该问一个问题！我觉得他们说得比较清楚，但没有给出确切的数字。。当我说架构时，我指的是负载平衡器、redis实例、应用程序服务器等，不使用云提供商，并为“暴力解决方案”支付大量费用