规模/架构挑战

Question

我最近接受了一家知名且非常成功的公司的采访，除了架构部分外，一切都很顺利 - 我卡住了，想出了一半的答案，但很明显我在这方面没有足够的经验区域。很公平，但我认为当涉及到这么大的规模时，如果没有经历过，你就不会获得经验，除非你能在其中一家公司找到一份工作，否则你不会获得经验……无论如何！从那以后我一直在考虑它，但还没有提出我认为很好的解决方案。

大致是这样的：

我们想为我们的客户做点好事。我们想要一个网站集 在用户可以输入他们的电子邮件地址的地方，我们会给他们一个 一张免费 X 的代金券（汉堡、出租车、流媒体月份、 任何公司可能提供）。我们将赠送其中的 1000 万个 代金券。我们预计，由于需求量很大，我们将在 5分钟。在任何情况下，我们都不得向单个用户（电子邮件地址）提供超过一张优惠券或给予超过分配的优惠券数量的优惠券数量，但它 不会是世界末日 稍微少一点。

设计一个可以处理这种规模的流量的系统架构

我真的很想听听一些意见和想法:)

Answer 1

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

我想到的第一个解决方案是使用 Lambda 函数和来自电子邮件的某种哈希函数作为凭证代码。这样我们就可以确保同一封电子邮件始终会收到相同的优惠券代码，因此无需检查存储空间。

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