找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 16121|回复: 4
收起左侧

[Facebook]FB onsite system design: tiny url

[复制链接]

2

主题

1

精华

47

积分

新米人

Rank: 1

积分
47
发表于 1-2-2016 08:11 AM | 显示全部楼层 |阅读模式

亲!马上注册或者登录会查看更多内容!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
去年面FB的题目,为了攒积分贴出来供大家参考,一下是我的主要思考步骤。欢迎拍砖。
Tiny url scale
Normally shortened url is composed of 6 characters [0-9,a-z,A-Z], total 62**6 is around 50 B

Use case
1. long url -> shortened url
    user input a long url, system output a shortened url

2. shortened url -> long url
    user input a short url, system redirect to the original long url

Non-functional consideration:
1. 1.3 B users will use this services(provided by the interviewer)
2. 100M requests per day
3. Store URL forever
4. Recent data are hot data
5. Expected response time: 100ms

Load analysis:

Write request: create shorten url from long url
1. 100M request/day  -> 1000 request/second
2. 2KB for long url, -> 2MB/s

Read request:
1. 10 times load than write

Abstract design: 2 parts
1. Web server cluster/ load balance
* server user request
* do shorten url logic
* save it to data storage
* render page

2. Data storage layer
* persistent data
* cache

Detail business logic:
How to mapping between long url <-> shorten url

Option 1:hashing
Hash: long url to a integer
Pros: easy

option 2:centralized increment
Pros: never get conflict
Cons: centeralize mechisim/synchronization

Data characteristics:
* No relationship between data
* Choose availability data store over consistency
* Create once and read many times
* No update, no deletion
* Read intensive load

评分

参与人数 1金钱 +3 收起 理由
Sophia + 3 感谢您的认真和用心的分享!大米满满送上!

查看全部评分

0

主题

0

精华

1

积分

新米人

Rank: 1

积分
1
发表于 1-2-2016 08:13 AM 来自美国米群网手机版 | 显示全部楼层
感谢lvrixp分享~~~
回复 支持 反对

使用道具 举报

0

主题

0

精华

4

积分

新米人

Rank: 1

积分
4
发表于 1-3-2016 05:06 AM | 显示全部楼层
感谢lvrixp分享~~~
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表