跟讀練習: How Does a URL Shortener Work? - 通過影片學習英語口語

選擇練習模式

每種模式都會開啟全屏練習室。

101 句

如果句子過短或過長，請點選 Edit 進行調整。

Everyone wonder what happens when you click a tiny URL?

You know, those short links like bit.ly and tinyurl, they somehow know exactly where to take you.

Today, we're going to reverse engineer how URL shorteners actually work.

And trust me, there's way more going on behind the scenes than you might think.

So what exactly does a URL shortener do?

Simple, it takes a massive URL like this Amazon link that goes on forever and turns it into something short and clean.

Click the short version and boom, you end up at the same place.

But here's where it gets interesting.

Let's say you're building the next bit.ly.

How many URLs do you think you need to handle?

Try 100 million new URLs every day.

That's over a thousand new short links created every single second.

And since people click links way more than they create them, you're looking at over 10,000 clicks per second.

Now think about storage.

Over 10 years, that's 365 billion URLs you need to keep track of.

Just storing the URLs themselves would take 36 terabytes.

So the real question becomes, how do you even generate these short URLs?

This is where the math gets fun.

Short URLs can use numbers and letters.

That's 62 possible characters, 0 through 9, lowercase A through Z, and uppercase A through Z.

But how short can we make them?

Let's work backwards.

We need 365 billion unique combinations.

With one character, you get 62 possibilities.

With two characters, 62 squared.

That's about 3000.

With three characters, 62 cubed. About 238,000.

Keep going you get to 7 characters, 62 to the 7th power.

That's 3.5 trillion possible combinations, way more than we need.

So 7 characters it is, but how do we actually create them?

There are two approaches, and they couldn't be more different.

The first approach, just hash the long URL.

Take any hash function like md5, run the long URL through it, and you get back a long string of random characters.

The problem?

That string is way too long.

Even the shortest hash gives you 32 characters when you only want 7.

So you take the first 7 characters and call it a day.

But wait, what happens when two different URLs give you the same first 7 characters?

You've got a collision.

Now you're stuck.

You have to try again with some variation of the original URL until you find 7 characters that nobody else is using.

Every time you want to create a short URL, you have to check if those 7 characters are already taken.

That's a lot of database lookups.

The second approach is way more elegant.

Instead of hashing, you just count.

Every time someone wants to shorten a URL, give you the next number in sequence.

URL number 1, number 2, number 3, and so on.

Then convert that number to what's called base 62.

Here's how that works.

Let's say you're on URL number 11157.

To convert to base 62, you divide by 62 over and over, keeping track of the remainders.

11157 divided by 62 is 179, remainder 59.

179 divided by 62 is 2, remainder 55.

2 divided by 62 is 0, remainder 2.

Now read the remainders backwards.

2, 55, 59.

In base 62, 2 stays as 2.

55 becomes T.

59 becomes X.

So URL number 11157 becomes 2TX.

Your short URL is tinyurl.com slash 2tx.

No collisions, no database lookups to check if it's taken, just clean math.

To trade off, you need a way to generate unique numbers across multiple servers.

That's its own engineering challenge.

And there's a security issue.

If someone figures out your pattern, they can guess the next short URL.

But for most cases, this approach is much cleaner.

Now, generating the short URL is just half of the problem.

The other half is what happens when someone clicks it.

When you click a short URL, the system needs to look up the original URL and redirect you there.

And this happens a lot more often than creating new short URLs.

So speed matters.

First, check the cache.

If the mapping is there, redirect immediately.

If not, hit the database, cache the result for next time, then redirect.

The redirect itself uses what's called a 301 status code.

That tells your browser this URL has permanently moved to the other location.

Your browser remembers this, so it might skip the URL shortener entirely next time.

But here's what makes this really interesting a scale.

A single database can handle 10,000 lookups per second, so you need multiple database replicas to spread the load.

Eventually, you will need to split the data across multiple databases entirely.

This is called sharding, and it's another whole engineering problem.

You need to figure out how to distribute the data evenly, how to route requests to the right database, what happens when one database goes down, how to rebalance when you add more servers.

And that's just the beginning.

In the real world, you also need to think about rate limiting so people can't spam your service.

You need analytics to track how many people click each link.

You need security to block malicious URLs.

What started as make this URL shorter becomes a lesson in distributed systems, caching, database scaling, and performance optimization.

Every major tech company has built some version of this.

Twitter shortens URL in tweets.

Slack does it in messages.

Even your company's internal tools probably do this.

And the techniques we talk about, unique ID generation, caching strategies, database sharding, these patterns show up everywhere.

Instagram uses similar ID generation for photos.

Netflix uses similar caching for video metadata.

Uber uses similar database splitting for trip data.

The next time you click a shortened link, you will know there's a host system working in milliseconds to get you where you're going.

And you will start recognizing these same patterns in every app you use.

Ready to ace your next technical interview?

100

Join our community where we offer comprehensive courses on system design, coding, behavioral questions, machine learning, and object-oriented design.

101

Learn more at bytebytego.com.

下載應用

流利口語所需的一切

AI 發音評分逐句打分

音標練習掌握每個音

詞彙學習建立你的詞庫

詞彙遊戲邊玩邊學

掃碼

Download on theApp Store Get it onGoogle Play

同頻道

FOR YOU

本課的詞彙與口語要點

這段影片共有 100 個句子、978 個單詞可供跟讀。講話部分時長為 6:41。說話人語速平穩，每分鐘約 146 個詞，很適合跟讀。只有 81% 的單詞屬於英語最常用的 3,000 詞，詞彙難度較高。

影片中的重點詞彙

影片中 15 個值得學習的單詞，附發音和釋義：

單詞	發音	釋義
database 名詞	/ˈdeɪtəˌbeɪs/	資料庫 /資料庫
remainder 名詞	/ɹəˈmeɪndɚ/	其餘 /其餘
cache 名詞	/kæʃ/	快取 /快取, 快取
divide 動詞	/dɪˈvaɪd/	分, 分裂
hash 名詞	/ˈhæʃ/	井號 /井號, 井字
server 名詞	/ˈsɝvɚ/	伺服器 /伺服器, 伺服器
string 名詞	/stɹɪŋ/	線 /線
mathematics 名詞	/mæθ(.ə)ˈmæt.ɪks/	數學 /數學, 算學 /算學
collision 名詞	/kəˈlɪʒn̩/	碰撞
distribute 動詞	/dɪˈstɹɪbjuːt/	分配
backward 形容詞	/ˈbækwɚd/	逆向
lesson 名詞	/ˈlɛs.ən/	課業 /課業, -課 /-課
technique 名詞	/tɛkˈniːk/	技術 /技術, 技巧
comprehensive 形容詞	/ˌkɑm.pɹəˈhɛn.sɪv/	全面的, 綜合的 /綜合的
sequence 名詞	/ˈsiː.kwəns/	序列, 順序 /順序

影片中出現的短語動詞

單詞	發音	釋義
figure out 動詞		弄清楚
go down 動詞		下降, 下去
look up 動詞	/ˌlʊk ˈʌp/	仰, 上看
show up 動詞		露面

需要注意的發音

說話人用了 9 次縮略和弱讀形式，例如 you're, can't, couldn't。請按聽到的簡短形式來說。

“sh” 和 “zh” 音: cache /kæʃ/, hash /ˈhæʃ/, collision /kəˈlɪʒn̩/, combinations /kɑmbɪˈneɪʃənz/, variation /ˌvɛəɹiˈeɪʃn̩/
長單詞——注意重音位置: mathematics /mæθ(.ə)ˈmæt.ɪks/, combinations /kɑmbɪˈneɪʃənz/, comprehensive /ˌkɑm.pɹəˈhɛn.sɪv/, permanently /ˈpɜː.mə.nənt.li/, behavioral /bɪˈheɪvjəɹəl/

如何用這段影片練習

先完整聽一遍影片，不要開口，記下不認識的單詞。
用正常速度逐句跟讀，每句重複到你的節奏與說話人一致為止。
錄下自己的聲音並與原聲對比，特別注意 database, remainder, cache 這類單詞。

什麼是跟讀法？

跟讀法 (Shadowing) 是一種有科學依據的語言學習技巧，最初開發用於專業口譯員的培訓，並由多語言者Alexander Arguelles博士普及。這個方法簡單而強大：您在聽英語母語原聲的同時立即大聲重複——就像是一個延遲1-2秒緊跟說話者的影子。與被動聽力或語法練習不同，跟讀法強迫您的大腦和口腔肌肉同時處理並模模擬實的講話模式。研究表明它能顯著提高發音準確性，語調，節奏，連讀，聽力理解和口語流利度——使其成為雅思口語備考和真實英語交流最有效的方法之一。

影子跟讀法: 閱讀完整分步指南 →

跟讀練習: How Does a URL Shortener Work? - 通過影片學習英語口語

選擇練習模式

下載應用

同頻道

The Secret Sauce Behind NoSQL: LSM Tree

Proxy vs Reverse Proxy (Real-world Examples)

Cache Systems Every Developer Should Know

Top 5 Redis Use Cases

System Design Was HARD - Until You Knew the Trade-Offs

8 Most Important System Design Concepts You Should Know

Everything You Need to Know About DNS: Crash Course System Design #4

CAP Theorem Simplified

What Is REST API? Examples And How To Use It: Crash Course System Design #3

System Design: Why is Kafka fast?

What Are Microservices Really All About? (And When Not To Use It)

Kubernetes Explained in 6 Minutes | k8s Architecture

System Design: Why is Kafka Popular?

What is API Gateway?

10+ Key Memory & Storage Systems: Crash Course System Design #5

What Is Redis Really About? Why Is It So Popular?

How Git Works: Explained in 4 Minutes

推薦影片

The Most Confused Concepts in Engineering

Everything Valuable from an MBA in 25 minutes

3.3k

What is This $3BN Machine Under New York?

Will YouTube Ever Run Out Of Video IDs?

How Bitcoin Works in 5 Minutes (Technical)

How Ad Blockers Work

System Design: How to Build an API Rate Limiter

10 JavaScript Interview Questions You HAVE TO KNOW

How do microSD Cards Store 2 TB in such a TINY space?

Traceroute: You're Probably Reading the Results Wrong