有几个方面的反馈可能会有所帮助：
1。与 S3 的 API 比较
S3 API 现在是一个 RESTful API（它曾经支持 SOAP），它将每个“文件”（实际上是由键索引的数据块）表示为 HTTP 资源，其中键是资源的 URI。您的 API 更像 RPC，因为每个 HTTP 资源都代表一个要执行的操作，并且 blob 的键是参数之一。
这是好事还是坏事取决于您想要实现的目标以及您想要采用的架构风格（虽然我是 REST 的粉丝，但这并不意味着您必须为所有应用程序），但是由于你被要求设计一个像 S3 这样的系统，你的答案将受益于一个明确的论据，即你为什么选择不像 S3 那样使用 REST。
2。连接事物的线
架构图往往是非常高级的——这是合适的——但有时会倾向于在框之间画线而不清楚这些线的含义。这是否意味着托管这些软件组件的基础设施之间存在网络连接？这是否意味着这些组件之间存在信息或数据流？
当您在图表中绘制一条线时，将多个框全部连接在一起，这意味着这些框之间存在某种关系。添加箭头时，进一步暗示关系遵循箭头的方向。但目前尚不清楚这种关系是什么，或者方向性为何如此重要。
从您的图表中可以推断出，Memcache 集群和文件存储集群都在向 Metrics/SLA 门户发送数据，但它们没有相互发送数据。或者 ELB 没有连接到微服务。显然情况并非如此。
3。混合物理、逻辑、网络和软件架构
- 一般架构类型
-
逻辑架构 - 往往更关注职能职责领域之间的信息流
-
物理架构 - 往往更关注可部署的组件，例如服务器、虚拟机、容器，但我也在此处对可安装的软件包进行分组，因为正在运行的可执行进程可能会承载逻辑架构中的多个元素
- 特定类型的架构
-
网络架构 - 关注机器和设备之间的网络连接 - 可能引用 VLAN、IP 范围、交换机、路由器等。
-
软件架构 - 侧重于软件程序设计的内部结构 - 可能涉及类、模块、包等。
您的图表包括一个负载均衡器（更物理）以及每个微服务（可能是物理的、逻辑的或软件的）一个单独的框，其中每个微服务负责不同类型的操作。目前尚不清楚每个微服务是否有自己的负载均衡器，或者负载均衡器是否是可以将路径映射到不同前端的第 7 层均衡器。
4。缺少上下文
虽然架构通常关注系统的内部结构，但考虑系统上下文也很重要 - 即系统需要与之交互的系统之外的重要元素是什么？例如预期的客户端及其连接方法是什么？
5。实际建筑设计
虽然上述反馈侧重于与您交流的方法，但更多的是关于实际设计。
- COTS 产品 - 您是否谈到了替代品以及为什么选择您选择的产品？或者它只是你知道的唯一一个。 Awareness of the options and ability to select the appropriate option for a given purpose is valuable.
- 缓存 - 您在文件存储前面有缓存，但微服务前面没有任何内容（边缘缓存或前端反向代理） - 假设微服务正在为流程增加一些价值，缓存它们的结果也可能是有用
- 数据的冗余和持久性 - 当您谈论故障转移的弹性时，数据存储的数据冗余和持久性是此类事情的关键要求，并且对如何实现这一点的一些明确参考将是有用的。请注意，这与服务的可用性略有不同。
- 性能 - 您谈到引入缓存层以提高性能，但不限定实际的性能要求 - 每秒存储或检索 100 个对象，1000 个还是数百万个？您需要知道这一点才能知道要构建什么
- 全球访问 - S3 是一个多区域/多数据中心解决方案 - 您的架构不引用多数据中心的任何方面，例如存储对象和元数据的复制
- 安全性 - 您参考了有关 AAA 的要求，但您提出的解决方案未定义负责安全性的组件，以及在哪个层或请求路径中的哪个点验证、接受或拒绝请求
6。好的
为了避免这种批评被认为过于消极，值得一提的是，您的方法有很多值得喜欢的地方 - 您对可能要求的评估是彻底的，很高兴看到包含安全性以及操作监控和 SLA 的预先考虑.
但是，回顾这个，我想知道它实际上是什么类型的工作 - 它看起来更像是云架构师角色的应用程序，而不是软件架构师角色，我希望看到更多关于包、模块、程序集、库和软件组件。
尽管如此，但也值得考虑 - 如果面试官在面试中问这个问题，他们在寻找什么？没有人希望您在 15 分钟内提出一个架构，该架构可以完成亚马逊工程师和架构师团队多年来构建和改进的工作！他们正在寻求思路和表达的清晰性、检查的彻底性、从明确陈述的假设中得出的合乎逻辑的结论，以及对行业标准和实践的知识和意识。
希望这对您有所帮助，祝您求职顺利！