第二版
要注意的
应用场景
用户添加订阅源
用户向订阅源获取消息
客户端整理消息。
用户点开消息
用户阅读消息
标记已读
API
addSource(url)
getUpdate(sourceUrl, lastPulledTime, maxReturn)
getUpdateNumberOnly(sourceUrl, lastPulledTime,
getFullContent(newsURL)
Data Model / Schema
Subscription table
sourceId, sourceURL, lastPolledTime, lastNumberedTime, unpulledMessage
News Table
sourceId, newsId, newsURL, preview, readOrNot, timeStamp
这两个数据库和我们常见的理解的不一样都是在手机上的。当然也可以是在网上。有一个很不一样的是由于是新闻， 过段时间这个消息就直接expire了，没必要一直存着吧（我的猜测不一定对，需要和面试官确认），
Working Solution
用户subscribe, 用户打开app后，系统查询sourceURL, 并主动向各个source 询问某个timestamp之后的消息。 各个信息源返回之后，存入local的数据库。客户端整理后按时间先后顺序显示。用户点进去之后，会主动或手动pull消息的html并显示在服务器上，并把消息标记为已读。
本地的数据库要以timestamp建2ndary index， primary index是newsId.
因为是以timestamp从后往前排序，经常要查询，所以要经常这么干。
把所有消息标记为已读， 就是遍历数据库，一个个改一下。由于数据都在本地，所以数据量不会很大。
翻页就是Select * from newTable order by timeStamp desc offset 20 Rows Fecth next 20 Rows only.
显示新的消息
如果Rss发推送， 则通过real time service收集推送显示出来。
如果RSS不发推送，则每10分钟向各个source pull一次问一下上次之后出现了多少新的消息，服务器只需要返回有多少数字就可以了。用户选择收新消息的时候再要完整的新消息preview。
Scale
Scale个毛呀，这是单机版的。。
网页版的可以按user id sharding. 定期删删数据就好了，新闻，一周以前的新闻就不要留了。
Push Model
如果rss可以push的话，subscribe的时候汇报一下用户的device token，有消息的时候就push一下。如果订阅者特别多的话，那就不要push了，让用户定期来pull。
第一版
Scenario:
用户登录推送新鲜事（要能区分 哪些是新的，哪些是旧的）
用户阅读post
设计多牛的系统：
有多少用户，每个用户订阅多少channel，每次读多少
Service
Get update service
Sort and order service
Storage service
Push vs Pull model
用push model的话可能太慢了，fan out太慢了。因为一个channel很多人订阅，这些channel都是明星用户。
Storage
需要什么 table
user table: user id, name, info,
post table: post id, channel id, timeStamp, title, preview, URL
channel table: channel id, address
subscription table: channel id, user id, subscription date, last read date
user - post table: user id, post id, readOrNot
post id can use timeStamp
Scale
Sharding：
user table, subscription table, user -- post table 都 按user id shard,
channel table， post table 按 channel id sharding，
如果停止订阅
从post table里， filter by channel id吧