Luyện nói tiếng Anh bằng Shadowing qua video: How Uber Scaled from One Server to 150 Million Reads Per Second

Chọn chế độ luyện tập

Mỗi chế độ mở một phòng luyện tập toàn màn hình.

134 câu

Nếu các câu quá ngắn hoặc quá dài, hãy bấm Edit để chỉnh sửa.

In 2009, Uber was starting with a Python mullet.

Năm 2009, Uber bắt đầu hoạt động với một kiến trúc hỗn hợp Python.

One application, one growing business.

Một ứng dụng, một doanh nghiệp đang phát triển.

By 2019, Uber reported more than 15 million trips a day.

Đến năm 2019, Uber báo cáo có hơn 15 triệu chuyến đi mỗi ngày.

And in 2025, its caching infrastructure reported over 150 million cache database row reads per second at peak.

Và vào năm 2025, cơ sở hạ tầng bộ nhớ đệm của nó đã ghi nhận hơn 150 triệu lượt đọc hàng cơ sở dữ liệu bộ nhớ đệm mỗi giây vào thời điểm cao điểm.

So how does a system grow at that scale?

Vậy thì làm thế nào mà một hệ thống có thể phát triển ở quy mô đó?

Let's build it step by step.

Imagine you are building Uber you start with one application

and a postgres database and this is called monolith

and all your main application features live inside one application

and early days that's not a bad thing it's easier to build test

and deploy code but now more rides are booing trips more drivers are sending updates

and your application has work to do if the application and database share one machine they compete for the CPU and RAM.

The database run queries, the application handle request and both need resources.

One solution is to move the database onto its own server.

Now the application and database have separate resources.

You can scale them independently but there is a catch.

They now communicate over a network and the database can still become a bottleneck.

Meanwhile your application is also getting more traffic.

So let's scale your application first the simplest option is to give your application server more cpu

and memory and this is called vertical scaling it can work well

when you are just starting out you don't need to redesign everything just

because traffic increases but one machine has limits and

if it fails your application may become unavailable

so instead of making one server bigger you can add more servers

and that is horizontal scaling now you have multiple servers handling request

but there's a new question when the request arrives

which server should handle it

so you put a load of answer in front of replication server

it distributes incoming requests across them it can use strategies like round robin

or lease connection

and health checks can help it avoid sending traffic to unhealthy server

now one server failing does not necessarily take down the whole application

but there is a other problem imagine a user logs in replication store their session on the first server

then the user's next request reaches a different server

that server may not have the session so how does it know

that you are logged in one option is to store session in a shared system such as redis

now any application server can retrieve the session

and other option is to use a token such as gwd

that carries signed claims that can reduce the need to look up a session on every request.

But remember, tokens don't eliminate every kind of server -side state.

The key idea is simple.

Don't make one application server the only place where information needed by the next request exists.

We've added application servers, but all of them still depend on database.

And every request does not necessarily need to read fresh data from it.

Some data gets requested repeatedly, and that is where caching comes in.

Imagine a request needs a piece of data.

First, the application checks the cache.

If the data is there, it returns it and that is cache hit.

If it is missing, the application fetches it from database

and can put it in the cache and that is a cache miss.

The next request may get the data without querying the database again.

But caching introduces a problem.

What happens when the original data changes?

The cached copy might become stale.

You can use techniques such as time to live or TTL to expire entries.

You can also use invalid cache data when the underlying data changes.

Strategies like write -through or write -around handle writes differently.

And there is no single strategy that's best for every workload.

Uber has built caching infrastructure called CacheFront.

In August 1995, Uber reported that it handled more than 150 million cache row reads per second at peak.

Notice what that number means.

It's cache database row reads handled by that infrastructure.

And it does not mean every database read across

Uber was subbed from the cache.

Caching can remove a lot of repeated work, but it does not solve every database problem.

Some applications read data far more often than updated.

For those workloads, you can introduce read replicas.

The primary database handle writes, replica receive copies of the data then application can send suitable read queries to those replicas

that take some read traffic away from the primary

but there is an important catch replication can take time the primary might have the latest update

while the replica is still catching up and this is called replication lack

so if a request need the fresh data you may need a read from the primary.

Replica help with re -capacity but they don't automatically solve right bottlenecks or storage limits.

Now imagine your trip data keeps growing.

Eventually one database may struggle to store and serve everything efficiently.

Uber ran into storage challenges with the Postgres -packed trip data in its early growth period.

It developed a system called SchemaLess on top of MySQL.

This brings us to another scaling technique.

It is called Sharding.

Instead of storing all the data on one database, you split it across multiple database groups.

For example, imagine dividing trips into groups based on hash of the trip identifier.

One group stores some trips, another group stores others.

The application needs a way to work out which group contains the requested trip.

And that is the basic idea.

This example explains sharding.

It is not a claim about Uber's exact partitioning algorithm okay

so sharding lets you distribute data and workload

but now your application need to know where each record live

and the workload might not be evenly distributed imagine one shard receiving far more requests than the others

that shard can become a bottleneck even when the rest are healthy

and this is also called a hot shard so sluting the data helps but it also makes data management more complicated.

Okay, so there is one more challenge.

As the developer team grow, more developers work on the same application.

A change in one area might affect other.

Deployment can become much harder to coordinate.

One response is to split the application into small services.

And Uber documented its move toward a microservice architecture in 2015.

So imagine this.

Payments, pricing, and trips matching as separate services.

100

These are illustrative examples of how an application can be divided.

101

Each service can have its own code base and deployment process.

102

Teams can work more independently, but now one user request might depend on several services working together.

103

And that creates a different kind of problem.

104

Okay, inside one application, calling a function is usually straightforward.

105

For example, a fare calculation function might take the trip details as input and return the calculated fare.

106

But when one service calls another service over a network, things change.

107

The other service might be slow or it might be unavailable or the network request might time out.

108

Now you need to handle failure across service boundaries.

109

Okay, so when an application has many services, finding the cause of slow request gets hard.

110

Was the delay in pricing, was it payments or was one service waiting on another?

111

So Uber developed Yaeger, a distributed tracing system to help engineer follow requests across services.

112

Tracing helps you to see where time is spent and where request is failing.

113

Without that visibility, debugging a distributed system becomes much harder.

114

Ok, as the services multiply, service discovery and communication also becomes more complicated.

115

A service needs to find the service it wants to call.

116

And the system need to handle those connections reliably.

117

So Uber developed Hyperband as a part of its service communication infrastructure.

118

So engineers also used general resilience patterns such as timeouts, retries and circuit breakers.

119

But those patterns need careful configuration.

120

Retries for example can make an overload service even busier.

121

So by July 2020, Uber had described an architecture with around 2200 critical microservices organized into 70 domains.

122

These 70 domains were not 70 services.

123

They were broader grouping used to organize services.

124

And that is important lesson here.

125

Microservices can be more independent but also create more dependence, more network calls, more operational complexity.

126

So just look at the progression.

127

You start with one application, then you separate the database, you add application servers, you share session state, you introduce caching and read applicas,

128

you shard the data, and eventually you split the application into services.

129

Each decision solves a problem, but each decision also introduces a new trade -off.

130

That's how production systems grow.

131

Not by adding every technology from the beginning, but by identifying the bottleneck, choosing a solution, and understanding the new problem that solution create.

132

When you are designing a system, don't just ask, what technology should I use?

133

Ask, what problem am I solving and what trade -off am I accepting?

134

Save this for your next systemline interview and follow for more.

Tải Ứng Dụng

Mọi thứ bạn cần để nói trôi chảy

Chấm điểm AIChấm từng câu nói

Luyện IPAThành thạo mọi âm

Từ vựngMở rộng vốn từ

Game Từ vựngHọc qua chơi

Quét QR

Download on theApp Store Get it onGoogle Play

FOR YOU

Video gợi ý

67 câu

Redis Crash Course - the What, Why and How to use Redis as your primary database

Daily ConversationUniversity StudentsWorking Adults

689 câu

Database Sharding! Designing Data-Intensive Applications chapter 6

Daily ConversationUniversity StudentsWorking Adults

462 câu

Expensive RTX 5090 for LLMs? NO. Use This Instead. (Tesla V100 SXM2 + Z8 G4, #RACERRRZ)

Daily ConversationUniversity StudentsWorking Adults

466 câu

DejaVue #E001 - The Need for Server-Side Rendering (SSR)

Daily ConversationUniversity Students

Từ vựng và ghi chú luyện nói cho bài học này

Bài luyện nói này dựa trên video “How Uber Scaled from One Server to 150 Million Reads Per Second”. Những từ được nhắc lại nhiều nhất trong bài: application, database, server, request, Uber. Video này có 134 câu và 1507 từ để luyện shadowing. Phần lời nói dài 9:46. Người nói nói với tốc độ tự nhiên, khoảng 154 từ mỗi phút, gần với hội thoại hằng ngày. Chỉ 79% số từ nằm trong 3.000 từ tiếng Anh thông dụng nhất, nên từ vựng khá khó.

Từ vựng quan trọng trong video

15 từ đáng học trong video, kèm phiên âm và nghĩa:

Từ	Phiên âm	Nghĩa
database danh từ	/ˈdeɪtəˌbeɪs/	cơ sở dữ liệu, CSDL
server danh từ	/ˈsɝvɚ/	trình chủ, máy chủ
cache danh từ	/kæʃ/	bộ nhớ đệm, vùng nhớ đệm
infrastructure danh từ	/ˈɪnfɹəˌstɹʌkt͡ʃə/	cơ sở hạ tầng
solve động từ	/sɒlv/	giải quyết
introduce động từ	/ˌɪntɹəˈdus/	giới thiệu
complicated tính từ	/ˈkɑm.plɪˌkeɪ.tɪd/	phức tạp
technique danh từ	/tɛkˈniːk/	kỹ thuật, kĩ thuật
architecture danh từ	/ˈɑː.kɪˌtɛk.t͡ʃə/	kiến trúc
log danh từ	/lɔɡ/	gỗ tròn
domain danh từ	/ˌdəʊˈmeɪ̯n/	đất đai, tài sản
depend động từ	/dɪˈpɛnd/	phụ thuộc
developer danh từ	/dɪˈvɛləpɚ/	nhà phát triển
trace danh từ	/tɹeɪs/	dấu, vết
divide động từ	/dɪˈvaɪd/	chia

Cụm động từ bạn sẽ nghe

Từ	Phiên âm	Nghĩa
look up động từ	/ˌlʊk ˈʌp/	ngước

Ngữ pháp trong video

Những cấu trúc người nói dùng nhiều nhất, kèm đúng cụm từ trong video:

Cấu trúc	Trong video
Câu bị động be + quá khứ phân từ — nhấn vào việc xảy ra, không phải người làm	is called · are logged · was subbed
Thì hiện tại hoàn thành have/has + quá khứ phân từ — việc đã xảy ra nhưng còn liên quan đến hiện tại	We've added · has built

Phát âm cần chú ý

Người nói dùng 6 dạng rút gọn, ví dụ don't, we've. Hãy nói theo dạng ngắn đúng như bạn nghe.

Âm “th”: algorithm /ˈælɡəɹɪðm̩/, unhealthy /ʌnˈhɛl.θi/, monolith /ˈmɑn.əˌlɪθ/
Âm “sh” và “zh”: cache /kæʃ/, operational /ˌɑ.pəˈɹeɪ.ʃə.nəl/, configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, progression /pɹəˈɡɹɛʃən/, calculation /ˌkælkjuˈleɪʃn̩/
Từ dài — đặt trọng âm cho đúng: infrastructure /ˈɪnfɹəˌstɹʌkt͡ʃə/, necessarily /ˌnɛs.əˈsɛɹ.ə.li/, complicated /ˈkɑm.plɪˌkeɪ.tɪd/, architecture /ˈɑː.kɪˌtɛk.t͡ʃə/, developer /dɪˈvɛləpɚ/

Những âm người Việt thường gặp khó:

Cụm phụ âm cuối — đọc đủ từng âm, đừng nuốt âm cuối: solve /sɒlv/, depend /dɪˈpɛnd/, deployment /dɪˈplɔɪmənt/, straightforward /ˌstɹeɪtˈfɔː(ɹ)wə(ɹ)d/, dependence /dɪˈpɛndəns/
Âm /tʃ/, /dʒ/ và /ʒ/ — tiếng Việt không có, đừng đọc thành “ch” hay “gi”: infrastructure /ˈɪnfɹəˌstɹʌkt͡ʃə/, architecture /ˈɑː.kɪˌtɛk.t͡ʃə/, fetch /fɛt͡ʃ/
Âm /æ/ — mở miệng rộng hơn âm “e”: cache /kæʃ/, algorithm /ˈælɡəɹɪðm̩/, calculate /ˈkælkjʊleɪt/, calculation /ˌkælkjuˈleɪʃn̩/, hash /ˈhæʃ/

Cách luyện với video này

Nghe hết video một lần, chưa cần nói, và ghi lại những từ bạn chưa biết.
Bắt đầu ở tốc độ 0,75×, nói đuổi từng câu, rồi quay lại tốc độ bình thường khi đã quen.
Ghi âm giọng mình rồi so với bản gốc, chú ý các từ như database, server, cache.

Phương Pháp Shadowing Là Gì?

Shadowing là kỹ thuật học ngôn ngữ có cơ sở khoa học, ban đầu được phát triển cho chương trình đào tạo phiên dịch viên chuyên nghiệp và được phổ biến rộng rãi bởi nhà đa ngôn ngữ học Dr. Alexander Arguelles. Nguyên lý cốt lõi đơn giản nhưng cực kỳ hiệu quả: bạn nghe tiếng Anh của người bản xứ và lặp lại to ngay lập tức — như một "cái bóng" (shadow) đuổi theo người nói với độ trễ chỉ 1–2 giây. Khác với luyện ngữ pháp hay học từ vựng bị động, Shadowing buộc não bộ và cơ miệng phải đồng thời xử lý và tái tạo ngôn ngữ thực tế. Các nghiên cứu khoa học xác nhận phương pháp này cải thiện đáng kể phát âm, ngữ điệu, nhịp điệu, nối âm, kỹ năng nghe và độ lưu loát khi nói — đặc biệt hiệu quả cho người luyện IELTS Speaking và muốn giao tiếp tiếng Anh tự nhiên như người bản ngữ.

Phương pháp shadowing: đọc hướng dẫn từng bước đầy đủ →

Luyện nói tiếng Anh bằng Shadowing qua video: How Uber Scaled from One Server to 150 Million Reads Per Second

Chọn chế độ luyện tập

Tải Ứng Dụng

8 Most Important System Design Concepts You Should Know

The Gig Economy is Full

Did Anthropic Kill Git?

Give me 31 minutes, I will make PyTorch click forever

How I deploy serverless containers for free

Agentic AI Frameworks Explained: Workflows, Multi-Agent, & Production

The Complete Guide to Hybrid Search in RAG (BM25 + Embeddings + Reranker)

The Only SaaS Moats Left in 2026

Redis Crash Course - the What, Why and How to use Redis as your primary database

Database Sharding! Designing Data-Intensive Applications chapter 6

Expensive RTX 5090 for LLMs? NO. Use This Instead. (Tesla V100 SXM2 + Z8 G4, #RACERRRZ)

DejaVue #E001 - The Need for Server-Side Rendering (SSR)

Từ vựng và ghi chú luyện nói cho bài học này

Từ vựng quan trọng trong video

Cụm động từ bạn sẽ nghe

Ngữ pháp trong video

Phát âm cần chú ý

Cách luyện với video này

Phương Pháp Shadowing Là Gì?