Use case/Scenario:
用户发tweet
用户follow别人
用户获取时间线
用户评论，转发(非核心功能)
Service
核心api
login (userName, password): return session key or exception
PostTweet(userName, content) : return a url or exception
getTimeLine(userName): return list of tweet, then organize by the app or web browser
- User Service， login时用到的
2。 Tweet service
又可以分为 a. Timeline service: 链接数据库
b. Post Twitter service， 链接数据库 - Friendship service： time line时用到的。链接数据库
- Media service，也是指向一个数据库
upload
download
感觉拆分成microservice的时候就是看哪些业务适合归并在一起。
一般对相同数据库的操作都可以group在一起。
Storage
User table
user id, name, password, last login
Friendship table
follower, followee, since time
Tweets table
Tweet id, user id, content, createdAt
File System for media
Working solution
使用pull model的solution
image.png
缺陷，读的时候会比较慢
使用push model的solution
为了解决读的比较慢的问题，再加一个new feed table.
用户发完帖子之后， 服务器会把它写到这个用户的每个follower的news feed里面去。这样用户登录的时候只需要拿自己的前一百条就好了。会快很多。
news feed table
user id, owner id, tweet id, created At.
为什么要用owner id？ 感觉可以当sharding key。
写news feed是一个很长的过程，可以用一个message queue来异步执行。
这个缺点就是比较慢 。。。
image.png
如果明星发帖了，对于在线的用户，如何让他第一时间知道，再开一个real time service, 用户订阅这个明星的channel，一量明星发帖了，就直接通知。有点小题大做的样子也可以让用户每十秒钟pull一次, cache明星。
