每当缓存丢失时，我们的服务器就会击中后端数据库。每当发生这种情况时，我们就可以更新缓存并将新条目传递给所有缓存副本。每个副本都可以通过添加新条目来更新它们的缓存。如果副本已经有该条目，则可以简单地忽略它。
九. 负载均衡我们可以在系统的三个地方添加负载均衡
客户端和应用服务器之间
应用服务器与数据库服务器之间的连接
应用服务器和缓存服务器之间
最初，我们可以使用简单的Round Robin方法，将传入请求平均分配到后端服务器。这种LB实现简单，而且不引入任何开销。这种方法的另一个好处是，如果一个服务器死机了，LB将停止向它发送任何流量。
轮询LB的问题是没有考虑服务器负载。如果服务器负载过重或速度变慢，LB不会停止向该服务器发送新的请求。为了解决这个问题，可以放置一个更智能的LB解决方案，定期查询后端服务器的负载，并基于此调整流量。
十. 数据清理短链是应该永久保存还是应该到期清除? 如果到达用户指定的过期时间，该链接将发生什么情况？
如果我们选择主动搜索过期链接来删除它们，这将给我们的数据库带来很大的压力。相反，我们可以缓慢地删除过期链接，并进行惰性清理。我们的服务将确保只有过期的链接将被删除，尽管一些过期链接可以活得更长，但永远不会返回给用户。
当用户试图访问过期链接时，我们可以删除链接并向用户返回一个错误
可以定期运行一个单独的Cleanup服务，从存储和缓存中删除过期的链接。该服务应该是非常轻量级的，并且只在用户流量预期较低时才可以调度运行
我们可以为每个链接设置一个默认的过期时间(例如，两年)。
在删除过期链接之后，我们可以将密钥放回key-db中以供重用。
应该删除6个月没有访问过的链接吗? 这可能有点棘手。由于存储变得越来越便宜，我们可以决定永远保持链接。
一个短 URL 被使用了多少次，用户位置是什么，等等？ 我们将如何存储这些统计信息？ 如果它是在每个视图上更新的 DB 行的一部分，那么当一个热点的 URL 受到大量并发请求的冲击时会发生什么？
一些值得跟踪的统计数据: 访问者的国家、访问日期和时间、涉及点击的网页、浏览器或访问页面的平台。
十二. 安全与权限用户是否可以创建私有URL或允许特定用户组访问URL。
我们可以在数据库中存储每个 URL 的权限级别（公共/私有）。 我们还可以创建一个单独的表来存储有权查看特定 URL 的用户 ID。 如果用户没有权限并尝试访问 URL，我们可以发回错误 (HTTP 401)。 鉴于我们将数据存储在像 Cassandra 这样的 NoSQL 宽列数据库中，表存储权限的密钥将是哈希（或 KGS 生成的密钥）。 这些列将存储有权查看 URL 的那些用户的用户 ID。