由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
JobHunting版 - fb设计题
相关主题
我的System Design总结请教个performance 相关的问题
12306 妙杀[系统设计]关于流量限制访问
再来继续比较,芒果和redis各什么时候用比较好?get Top 1million most frequent entries in past 24 hour
Load balancer: NGINX vs HAproxy vs hardware问个snapchat的设计题
一道脸家的系统设计常考题Java Jobs
我也来说说我Amazon的onsite经历吧QPS多高算高?
PayPal User & on Boarding组 staff 1面经公司最近持续招人中(软件工程师)
贡献个系统设计题兼讨论准备面试刷的这些题,实际工作应用中能用到多少?
相关话题的讨论汇总
话题: user话题: cache话题: write话题: post话题: should
进入JobHunting版参与讨论
1 (共1页)
c********d
发帖数: 173
1
面试职位是后端
遇到个设计题:设计fb like button
讨论到存储、实时更新等等。请教大家这个应该怎么回答最好
r*********n
发帖数: 32
2
实时更新那就Long poll 咯
存储主要是考虑到大V发了个帖子,一堆人点赞会有瓶颈吧。
那就存内存里咯,顺便搞个write ahead log, 异步更新DB,如何?

【在 c********d 的大作中提到】
: 面试职位是后端
: 遇到个设计题:设计fb like button
: 讨论到存储、实时更新等等。请教大家这个应该怎么回答最好

r*****s
发帖数: 1815
3
#1 QPS:
Probably 10k~100k concurrent access (my guess)
Meaning we need to heavily cache the data. We may need some write through
cache in place. Well sharded.
resource wise, I'm not worried at all. for cache https://redis.io/topics/
benchmarks) redis can be super fast. for persistency with nosql we can
achieve almost infinite scalability.
our system should provide the following APIs:
- Like(user, post)
- Unlike(user, post)
- Liked(user, post)
- CountLikes(post)
Extra:
- RecentLikes(user)
- FriendsLiked(user, post)
If we only consider the first 4 APIs, it is obvious: post id should be hash/
partition key and user id should be range/sort key.
The extras can have longer latencies - by using offline process or secondary
global index.
Or, we can store recent likes in user's metadata. Or it could be just
published as an implicit timeline entry.
#2 access pattern:
Read dominant. can be 10x-50x comparing to writes.
#3 consistency:
Eventual consistency ok, but the writer clients should read back same value.
We may need to consider sticky sessions (which can be bad for load-
balancing. but luckily we don't need to worry too much about server going
down.)
Another approach we can consider/combine is local (client) cache. This might
be hard on browser (because user could use several browsers on same
computer!), but in mobile app it is easy. As far as I know FB uses local
cache trick on several products to offload their services.
#4 availability:
very important. if you do not allow people to like posts, some attention
whore may DIE because of this unavailability.
combining #3 and #4 we decide it should be an AP system. in network
partition, we store Like data in each partition, and after recovering, we
merge as best as we can.
#5 how to shard?
I always prefer quorum in loosely consistent systems. it has better fault
tolerance than master-slave or leader/leaders systems. Availability is
important in our use case. It doesn't mean we need to implement it, but when
choosing our tools, we should use cassandra / dynamodb other than mongodb /
mysql
#7 improve latency?
latency is important too. however we still need to confirm the write. (
immediate notice that the like didn't take effect vs find it after 1 hour or
never find out)
as mentioned above, use write thru cache. also tune the w/r values in quorum
so we have better write performance with acceptable fault tolerance.
#6 how to balance load in app layer?
load balancer....
在下只是餐馆洗碗的,设计功力有限。。暂时想到这么多,大牛们不要见笑。。。
r*****s
发帖数: 1815
4
我还是倾向用write through。。。不会太慢的。。。
write back的话有一点风险。不过可以商量。。。


: 实时更新那就Long poll 咯

: 存储主要是考虑到大V发了个帖子,一堆人点赞会有瓶颈吧。

: 那就存内存里咯,顺便搞个write ahead log, 异步更新DB,如何?



【在 r*********n 的大作中提到】
: 实时更新那就Long poll 咯
: 存储主要是考虑到大V发了个帖子,一堆人点赞会有瓶颈吧。
: 那就存内存里咯,顺便搞个write ahead log, 异步更新DB,如何?

1 (共1页)
进入JobHunting版参与讨论
相关主题
准备面试刷的这些题,实际工作应用中能用到多少?一道脸家的系统设计常考题
话说为啥FB一聊天软件要那么多码工?我也来说说我Amazon的onsite经历吧
回馈本版,最有名的出租车公司onsite面经PayPal User & on Boarding组 staff 1面经
为啥有的公司会选择Java Spring 框架而不是ASP.NET MVC呢贡献个系统设计题兼讨论
我的System Design总结请教个performance 相关的问题
12306 妙杀[系统设计]关于流量限制访问
再来继续比较,芒果和redis各什么时候用比较好?get Top 1million most frequent entries in past 24 hour
Load balancer: NGINX vs HAproxy vs hardware问个snapchat的设计题
相关话题的讨论汇总
话题: user话题: cache话题: write话题: post话题: should