【问题标题】:Checking subscription status realtime实时查看订阅状态
【发布时间】:2021-01-04 03:45:40
【问题描述】:

考虑示例聊天应用程序,其中用户购买月度/年度订阅(Amazon Prime 等订阅)。

一旦订阅到期,用户应该无法在应用中发送消息。

用户可以在原始订阅结束日期之前结束订阅。

我想到的一个解决方案(前端) - 在应用程序中缓存结束日期,并在每次“发送消息”操作之前,比较结束日期​​和当前日期。

但问题是 - 如果用户提前结束订阅,用户仍然可以发送消息。

如何推送更新缓存中的新订阅结束日期。

另一个解决方案是(后端) - 我在后端有一个表,用于存储订阅详细信息,如订阅 ID、用户 ID、订阅结束日期。所以在任何“发送消息”操作之前,查询订阅表并比较日期,然后继续/取消进一步的操作。

第一季度。我应该使用后端解决方案,还是请您分享一些对前端方法的改进或此场景的任何最佳实践?

第二季度。还将订阅详细信息存储在单独的表格最佳实践或任何好的设计中。 ?

PS- 示例聊天应用程序基于 AWS Amplify Datastore

【问题讨论】:

  • 如果您正在寻找“意见”,您可能会得到更好的回复:reddit.com/r/aws

标签: amazon-web-services design-patterns aws-amplify subscription


【解决方案1】:

让我尝试分解答案并发表我的意见。我还想提一下,这些问题的解决方案是由规模和各种权衡决定的。

Q1-

如果发送消息会产生不利影响,则切勿仅依赖前端解决方案,因为它很容易绕过它们。您可以使用混合来确保后端的负载不会很高。

为订阅添加前端缓存将确保您能够在缓存未被篡改的情况下过滤前端的大部分消息。

在队列之前添加一项服务,用于验证用户订阅是否已过期,从而增加了一层安全性。如果用户订阅有效,则将消息推送到队列,否则将引发错误。这样任何不良行为者也不会滥用系统。

Q2-

根据用例和负载,您可以为订阅本身提供单独的表或单独的微服务。

什么时候有单独的微服务?

当您的系统中的多个应用程序需要订阅数据并且需要具有自己独立于其他应用程序的可扩展性时,拥有单独的微服务可能会有所帮助。

什么时候有单独的桌子? 在其他情况下,您觉得添加服务将是矫枉过正。您可以将数据单独保存在不同的表/数据库中,让您可以灵活地更改订阅,甚至在将来轻松提取它。

【讨论】:

  • fetch current subscription expiry for x seconds flow 是什么?我理解除了这个之外的所有流程
  • 您可以通过获取订阅的当前到期时间来更新前端的缓存并添加 X 秒 TTL 以便您不断刷新此数据。 X 可以很大(5-10 分钟),也可以很小,例如 10 秒,具体取决于您的预期 QPS。
  • Q1 的解决方案 - 因为我们在后端进行检查,所以我认为我们不需要在前端缓存,以避免检查两次。 Q2 的解决方案-我会使用单独的表格,因为在我的场景中逻辑并不复杂。
猜你喜欢
  • 1970-01-01
  • 2022-07-22
  • 2018-05-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-03-17
  • 2017-06-18
相关资源
最近更新 更多