D**F
发帖数: 76 | 1 最近看板上一道脸家的系统设计常考题，如何设计呢？
要求
脸家 的 privacy setting 设计，怎么设计api，code大概怎么写，使用哪些数据，数
据怎么存，要支持下列功能
仅朋友可见，
朋友的朋友可见
对某些用户组成的自定义的group可见 |
j*****g
发帖数: 254 | 2 is it close to online game servers but much larger scale?
nosql db
one obj store each account scope
when an account is updated, update all related accounts scope
10bn active accounts, daily 1000 access per account
when shard by region, per region will be 100mn accounts
one server grid per region is attached to couple file servers |
D**F
发帖数: 76 | 3 多谢回复
这里的privacy是指发的帖子、图片、视频的可见度，有点像朋友圈发帖的“让谁看”
、“不让谁看”
【在 j*****g 的大作中提到】
: is it close to online game servers but much larger scale?
: nosql db
: one obj store each account scope
: when an account is updated, update all related accounts scope
: 10bn active accounts, daily 1000 access per account
: when shard by region, per region will be 100mn accounts
: one server grid per region is attached to couple file servers
|
j*****g
发帖数: 254 | |
r*****s
发帖数: 1815 | 5 The problem is that this is a little island in a big ocean, a really big...
Sorry I mean this is a system which needs to be injected into many other sub
systems so it's messy and too hard to be described here in a post.
However we can quickly go over some basic stuffs.
# we ignore the QPS and scalability bullshits here
* What are the requirements?
1. user can CRUD groups. **
2. user can assign group(s) to a post to whitelist/blacklist people in group
for the post***
3. user will not see other's post if the user is not granted permission
according to the permission model.
** What will happen if user post something, assign a group to it and later
delete the group?
** Define priorities of whitelist/blacklist. Who should be granted
permission to the post if one of the lists is missing?
* What are the APIs?
1. CRUD group. (of course it needs authentication**) - can be used directly
by end customer with proper auth method.
2. create_post(post, whitelist, blacklist) - whitelist and blacklist can be
just 2 extra fields in post's json payload. here we list them explicitly as
parameters just for display purpose. (don't buy it.) with proper auth method
it can be called by end user directly
3. check_permission(post, user) - only be called in backend. frontend calls
doesn't make much sense. This API will be called when we generate TL, list
posts on the wall, etc... It'll be better to have a batch API.
** When I say end user, I mean user using browser or mobile app.
** What auth method would you use?
** What will a batch API look like?
* What will be the storage structure for group info?
1. Sharded by user. (user id as hash key)
2. Store as json documents.
* What will be the storage structure for post/group relationship?
1. Sharded by user id.
2. Sorted by post-id (post id as sort key).
3. Store as json document. Reference to group id.
* Any other thoughts on storage structure?
1. Use graph based data base. posts, groups and users can be modeled as
vertexes, relationships as edges.
2. Or, use RDMS...????
: 多谢回复
: 这里的privacy是指发的帖子、图片、视频的可见度，有点像朋友圈发帖的“让
谁看”
: 、“不让谁看”
We have committed the Golden Rule to memory; let us now commit it to life
.
Edwin Markham
【在 D**F 的大作中提到】
: 多谢回复
: 这里的privacy是指发的帖子、图片、视频的可见度，有点像朋友圈发帖的“让谁看”
: 、“不让谁看”
|
r*****s
发帖数: 1815 | 6 I know facebook uses cpp and php a lot.
If they use Java I'd suggest the permission API to provide annotations to
help developers get a cleaner implementation and alleviate integration pains
. It's also better for static analysis. Not sure what's the options (if any)
for php.
: The problem is that this is a little island in a big ocean, a
really
big...
: Sorry I mean this is a system which needs to be injected into
many
other sub
: systems so it's messy and too hard to be described here in a
post.
: However we can quickly go over some basic stuffs.
: # we ignore the QPS and scalability bullshits here
: * What are the requirements?
: 1. user can CRUD groups. **
: 2. user can assign group(s) to a post to whitelist/blacklist
people in
group
: for the post***
: 3. user will not see other's post if the user is not granted
permission
Freedom is what you do with what's been done to you.
Jean-Paul Sartre
【在 r*****s 的大作中提到】
: The problem is that this is a little island in a big ocean, a really big...
: Sorry I mean this is a system which needs to be injected into many other sub
: systems so it's messy and too hard to be described here in a post.
: However we can quickly go over some basic stuffs.
: # we ignore the QPS and scalability bullshits here
: * What are the requirements?
: 1. user can CRUD groups. **
: 2. user can assign group(s) to a post to whitelist/blacklist people in group
: for the post***
: 3. user will not see other's post if the user is not granted permission
|
j**********r
发帖数: 3798 | 7 所有的这些题不过是读写的取舍。任何人发的帖子，可以只写自己timeline，可以写朋
友timeline，也可以写朋友的朋友timeline。写可以部分同步部分异步，读也是如此。
根据N的大小和读写的需求可以有各种取舍。关键就是把这些需求都确定了，再开始取
舍。通常而言，N大就要靠写。 |
W***o
发帖数: 6519 | 8 我onsite 也遇到了这个问题，感觉答的不错，因为最后面试官问我关于朋友的朋友的
问题时，我的回答对他很有共鸣。
我onsite前读了下面这个engineering blog两遍，感觉挺有启发意义：
https://www.facebook.com/notes/facebook-engineering/under-the-hood-building-
out-the-infrastructure-for-graph-search/10151347573598920/
其实每个timeline的帖子可以携带metadata，这些metadata就是系统设计的trade-off
，因为为了避免重复读取数据库；如果有数据库操作，比如删除或屏蔽一个朋友，
这个时候可以利用pub-sub来对相应的metadata进行更改
对某些用户组，我当时参考了unix/linux的用户组设计，用户自己设置一个enum来区别
每个用户组，比如就用id value： 1， 2， 3， 4 来给用户分组 |
r*****s
发帖数: 1815 | 9 大概这就是fb和我们作坊的思路区别。。。
我们这地方喜欢独立的service，所以尽量少加metadata。。。都是另开一坨。。。
: 我onsite 也遇到了这个问题，感觉答的不错，因为最后面试官问我关于朋友的
朋友的
: 问题时，我的回答对他很有共鸣。
: 我onsite前读了下面这个engineering blog两遍，感觉挺有启发意义：
: https://www.facebook.com/notes/facebook-engineering/under-the-hood-
building-
: out-the-infrastructure-for-graph-search/10151347573598920/
: 其实每个timeline的帖子可以携带metadata，这些metadata就是系统设计的
trade-off
: ，因为为了避免重复读取数据库；如果有数据库操作，比如删除或屏蔽一个朋友，
: 这个时候可以利用pub-sub来对相应的metadata进行更改
: 对某些用户组，我当时参考了unix/linux的用户组设计，用户自己设置一个enum
来区别
: 每个用户组，比如就用id value： 1， 2， 3， 4 来给用户分组
【在 W***o 的大作中提到】
: 我onsite 也遇到了这个问题，感觉答的不错，因为最后面试官问我关于朋友的朋友的
: 问题时，我的回答对他很有共鸣。
: 我onsite前读了下面这个engineering blog两遍，感觉挺有启发意义：
: https://www.facebook.com/notes/facebook-engineering/under-the-hood-building-
: out-the-infrastructure-for-graph-search/10151347573598920/
: 其实每个timeline的帖子可以携带metadata，这些metadata就是系统设计的trade-off
: ，因为为了避免重复读取数据库；如果有数据库操作，比如删除或屏蔽一个朋友，
: 这个时候可以利用pub-sub来对相应的metadata进行更改
: 对某些用户组，我当时参考了unix/linux的用户组设计，用户自己设置一个enum来区别
: 每个用户组，比如就用id value： 1， 2， 3， 4 来给用户分组
|
D**F
发帖数: 76 | 10 那个metadata存的是什么，存在哪里,可不可以再展开来说说~
building-
off
【在 W***o 的大作中提到】
: 我onsite 也遇到了这个问题，感觉答的不错，因为最后面试官问我关于朋友的朋友的
: 问题时，我的回答对他很有共鸣。
: 我onsite前读了下面这个engineering blog两遍，感觉挺有启发意义：
: https://www.facebook.com/notes/facebook-engineering/under-the-hood-building-
: out-the-infrastructure-for-graph-search/10151347573598920/
: 其实每个timeline的帖子可以携带metadata，这些metadata就是系统设计的trade-off
: ，因为为了避免重复读取数据库；如果有数据库操作，比如删除或屏蔽一个朋友，
: 这个时候可以利用pub-sub来对相应的metadata进行更改
: 对某些用户组，我当时参考了unix/linux的用户组设计，用户自己设置一个enum来区别
: 每个用户组，比如就用id value： 1， 2， 3， 4 来给用户分组
|
l*******i
发帖数: 25 | 11 我onsite 也遇到了这个问题，感觉答的不错，因为最后面试官问我关于朋友的朋友的
问题时，我的回答对他很有共鸣。
Wardo 大侠, Thanks for the post. Would you mind sharing the question and
your answers? Thanks |
