The Setup:
Imagine a 'twitter like' service where a user submits a post, which is then read by many (hundreds, thousands, or more) users.
我的问题是关于构建缓存的最佳方法&；优化数据库以实现快速访问&；许多人阅读，但仍保留历史数据，以便用户(如果他们愿意)看到旧帖子.这里的假设是，90%的用户只对新东西感兴趣，而旧东西偶尔会被访问.这里的另一个假设是，我们希望针对90%进行优化，如果旧的10%需要更长的时间来检索，这是可以的.
考虑到这一点，我的研究似乎有力地指向了一个方向，即对90%的用户使用缓存，然后将帖子也存储在另一个长期的持久系统中.到目前为止，我的 idea 是使用Redis进行缓存.其优点是Redis速度非常快，并且内置了pub/sub，非常适合向许多人发布帖子.然后，我考虑使用MongoDB作为一个更永久的数据存储，来存储那些在Redis到期后将被访问的帖子.
Questions:
1. Does this architecture hold water? Is there a better way to do this?
2. Regarding the mechanism for storing posts in both the Redis & MongoDB, I was thinking about having the app do 2 writes: 1st - write to Redis, it then is immediately available for the subscribers. 2nd - after successfully storing to Redis, write to MongoDB immediately. Is this the best way to do it? Should I instead have Redis push the expired posts to MongoDB itself? I thought about this, but I couldn't find much information on pushing to MongoDB from Redis directly.