Shadowing-Übung: How Uber Scaled from One Server to 150 Million Reads Per Second - Englisch Sprechen Lernen mit Video
Übungsmodus wählen
Jeder Modus öffnet einen Übungsraum im Vollbild.
134 Sätze
Wenn Sätze zu kurz oder zu lang sind, klicke auf Edit, um sie anzupassen.
1
In 2009, Uber was starting with a Python mullet.
2
One application, one growing business.
3
By 2019, Uber reported more than 15 million trips a day.
4
And in 2025, its caching infrastructure reported over 150 million cache database row reads per second at peak.
5
So how does a system grow at that scale?
6
Let's build it step by step.
7
Imagine you are building Uber you start with one application
8
and a postgres database and this is called monolith
9
and all your main application features live inside one application
10
and early days that's not a bad thing it's easier to build test
11
and deploy code but now more rides are booing trips more drivers are sending updates
12
and your application has work to do if the application and database share one machine they compete for the CPU and RAM.
13
The database run queries, the application handle request and both need resources.
14
One solution is to move the database onto its own server.
15
Now the application and database have separate resources.
16
You can scale them independently but there is a catch.
17
They now communicate over a network and the database can still become a bottleneck.
18
Meanwhile your application is also getting more traffic.
19
So let's scale your application first the simplest option is to give your application server more cpu
20
and memory and this is called vertical scaling it can work well
21
when you are just starting out you don't need to redesign everything just
22
because traffic increases but one machine has limits and
23
if it fails your application may become unavailable
24
so instead of making one server bigger you can add more servers
25
and that is horizontal scaling now you have multiple servers handling request
26
but there's a new question when the request arrives
27
which server should handle it
28
so you put a load of answer in front of replication server
29
it distributes incoming requests across them it can use strategies like round robin
30
or lease connection
31
and health checks can help it avoid sending traffic to unhealthy server
32
now one server failing does not necessarily take down the whole application
33
but there is a other problem imagine a user logs in replication store their session on the first server
34
then the user's next request reaches a different server
35
that server may not have the session so how does it know
36
that you are logged in one option is to store session in a shared system such as redis
37
now any application server can retrieve the session
38
and other option is to use a token such as gwd
39
that carries signed claims that can reduce the need to look up a session on every request.
40
But remember, tokens don't eliminate every kind of server -side state.
41
The key idea is simple.
42
Don't make one application server the only place where information needed by the next request exists.
43
We've added application servers, but all of them still depend on database.
44
And every request does not necessarily need to read fresh data from it.
45
Some data gets requested repeatedly, and that is where caching comes in.
46
Imagine a request needs a piece of data.
47
First, the application checks the cache.
48
If the data is there, it returns it and that is cache hit.
49
If it is missing, the application fetches it from database
50
and can put it in the cache and that is a cache miss.
51
The next request may get the data without querying the database again.
52
But caching introduces a problem.
53
What happens when the original data changes?
54
The cached copy might become stale.
55
You can use techniques such as time to live or TTL to expire entries.
56
You can also use invalid cache data when the underlying data changes.
57
Strategies like write -through or write -around handle writes differently.
58
And there is no single strategy that's best for every workload.
59
Uber has built caching infrastructure called CacheFront.
60
In August 1995, Uber reported that it handled more than 150 million cache row reads per second at peak.
61
Notice what that number means.
62
It's cache database row reads handled by that infrastructure.
63
And it does not mean every database read across
64
Uber was subbed from the cache.
65
Caching can remove a lot of repeated work, but it does not solve every database problem.
66
Some applications read data far more often than updated.
67
For those workloads, you can introduce read replicas.
68
The primary database handle writes, replica receive copies of the data then application can send suitable read queries to those replicas
69
that take some read traffic away from the primary
70
but there is an important catch replication can take time the primary might have the latest update
71
while the replica is still catching up and this is called replication lack
72
so if a request need the fresh data you may need a read from the primary.
73
Replica help with re -capacity but they don't automatically solve right bottlenecks or storage limits.
74
Now imagine your trip data keeps growing.
75
Eventually one database may struggle to store and serve everything efficiently.
76
Uber ran into storage challenges with the Postgres -packed trip data in its early growth period.
77
It developed a system called SchemaLess on top of MySQL.
78
This brings us to another scaling technique.
79
It is called Sharding.
80
Instead of storing all the data on one database, you split it across multiple database groups.
81
For example, imagine dividing trips into groups based on hash of the trip identifier.
82
One group stores some trips, another group stores others.
83
The application needs a way to work out which group contains the requested trip.
84
And that is the basic idea.
85
This example explains sharding.
86
It is not a claim about Uber's exact partitioning algorithm okay
87
so sharding lets you distribute data and workload
88
but now your application need to know where each record live
89
and the workload might not be evenly distributed imagine one shard receiving far more requests than the others
90
that shard can become a bottleneck even when the rest are healthy
91
and this is also called a hot shard so sluting the data helps but it also makes data management more complicated.
92
Okay, so there is one more challenge.
93
As the developer team grow, more developers work on the same application.
94
A change in one area might affect other.
95
Deployment can become much harder to coordinate.
96
One response is to split the application into small services.
97
And Uber documented its move toward a microservice architecture in 2015.
98
So imagine this.
99
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.
App herunterladen
Alles, was du zum fließenden Sprechen brauchst
KI-AussprachebewertungJeder Satz bewertet
IPA-TrainingJeden Laut meistern
WortschatzBaue deinen Wortschatz auf
VokabelspielSpielend lernen
FOR YOU
Empfohlenes Video
C18
67 Sätze
8 Most Important System Design Concepts You Should Know
Daily ConversationUniversity StudentsWorking Adults
C15
183 Sätze
The Gig Economy is Full
Daily ConversationUniversity StudentsWorking Adults
C11
65 Sätze
Did Anthropic Kill Git?
Daily ConversationUniversity StudentsWorking Adults
C11
498 Sätze
Give me 31 minutes, I will make PyTorch click forever
Daily ConversationUniversity Students
C11
78 Sätze
How I deploy serverless containers for free
Daily ConversationUniversity StudentsWorking Adults
C11
124 Sätze
Agentic AI Frameworks Explained: Workflows, Multi-Agent, & Production
Daily ConversationUniversity StudentsWorking Adults
C11
847 Sätze
The Complete Guide to Hybrid Search in RAG (BM25 + Embeddings + Reranker)
Daily ConversationUniversity Students
C11
623 Sätze
The Only SaaS Moats Left in 2026
Daily ConversationUniversity StudentsWorking Adults
C1231 Sätze
Redis Crash Course - the What, Why and How to use Redis as your primary database
Daily ConversationUniversity StudentsWorking Adults
C11
689 Sätze
Database Sharding! Designing Data-Intensive Applications chapter 6
Daily ConversationUniversity StudentsWorking Adults
C11
462 Sätze
Expensive RTX 5090 for LLMs? NO. Use This Instead. (Tesla V100 SXM2 + Z8 G4, #RACERRRZ)
Daily ConversationUniversity StudentsWorking Adults
C11
466 Sätze
DejaVue #E001 - The Need for Server-Side Rendering (SSR)
Daily ConversationUniversity Students
Wortschatz und Sprechhinweise zu dieser Lektion
Diese Sprechübung basiert auf dem Video „How Uber Scaled from One Server to 150 Million Reads Per Second“. Diese Wörter kommen am häufigsten vor: application, database, server, request, Uber. Dieses Video enthält 134 Sätze und 1507 Wörter zum Nachsprechen. Der gesprochene Teil dauert 9:46. Der Sprecher spricht in natürlichem Tempo, etwa 154 Wörter pro Minute, ähnlich wie im Alltagsgespräch. Nur 79 % der Wörter gehören zu den 3.000 häufigsten im Englischen, der Wortschatz ist also anspruchsvoll.
Wichtiger Wortschatz in diesem Video
15 lernenswerte Wörter aus dem Video, mit Aussprache und Bedeutung:
| Wort | Aussprache | Bedeutung |
|---|---|---|
| database Substantiv | /ˈdeɪtəˌbeɪs/ | Datenbank |
| server Substantiv | /ˈsɝvɚ/ | Server |
| cache Substantiv | /kæʃ/ | Cache, Zwischenspeicher |
| distribute Verb | /dɪˈstɹɪbjuːt/ | aufteilen, verteilen |
| replica Substantiv | /ˈɹɛplɪkə/ | Nachbildung, exakte Kopie |
| infrastructure Substantiv | /ˈɪnfɹəˌstɹʌkt͡ʃə/ | Infrastruktur |
| solve Verb | /sɒlv/ | lösen |
| introduce Verb | /ˌɪntɹəˈdus/ | vorstellen, bekannt machen |
| query Substantiv | /ˈkwɪɹ.i/ | Frage |
| necessarily Adverb | /ˌnɛs.əˈsɛɹ.ə.li/ | notwendigerweise, nötig |
| complicated Adjektiv | /ˈkɑm.plɪˌkeɪ.tɪd/ | kompliziert, umständlich |
| technique Substantiv | /tɛkˈniːk/ | Technik |
| architecture Substantiv | /ˈɑː.kɪˌtɛk.t͡ʃə/ | Architektur, Baustil |
| log Substantiv | /lɔɡ/ | Rundholz (forestial), Langholz (forestial) |
| domain Substantiv | /ˌdəʊˈmeɪ̯n/ | Domäne, Gebiet |
Phrasal Verbs, die du hören wirst
| Wort | Aussprache | Bedeutung |
|---|---|---|
| look up Verb | /ˌlʊk ˈʌp/ | bergauf gehen, aufwärtsgehen |
| take down Verb | herunternehmen, abnehmen | |
| work out Verb | /ˌwɝk ˈaʊt/ | ausrechnen |
Grammatik in diesem Video
Die Strukturen, die der Sprecher am häufigsten verwendet, mit den genauen Worten aus dem Video:
| Struktur | Im Video |
|---|---|
| Passiv be + Partizip Perfekt – wichtig ist, was geschieht, nicht wer es tut | is called · are logged · was subbed |
| Present Perfect have/has + Partizip Perfekt – eine vergangene Handlung, die jetzt noch wichtig ist | We've added · has built |
Aussprache, auf die du achten solltest
Der Sprecher verwendet 6 Kurzformen und abgeschwächte Formen, zum Beispiel don't, we've. Sprich sie in der kurzen Form, so wie du sie hörst.
- Die „th“-Laute: algorithm /ˈælɡəɹɪðm̩/, unhealthy /ʌnˈhɛl.θi/, monolith /ˈmɑn.əˌlɪθ/
- Die Laute „sh“ und „zh“: cache /kæʃ/, operational /ˌɑ.pəˈɹeɪ.ʃə.nəl/, configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, progression /pɹəˈɡɹɛʃən/, calculation /ˌkælkjuˈleɪʃn̩/
- Lange Wörter – auf die Betonung achten: 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ɚ/
Laute, die Deutschsprachigen schwerfallen:
- /w/ — mit runden Lippen, nicht wie das deutsche „w“ (/v/): query /ˈkwɪɹ.i/, meanwhile /ˈmiːnwaɪl/, straightforward /ˌstɹeɪtˈfɔː(ɹ)wə(ɹ)d/
- Stimmhafter Auslaut — /b/, /d/, /g/, /z/, /v/ am Wortende nicht verhärten: solve /sɒlv/, complicated /ˈkɑm.plɪˌkeɪ.tɪd/, log /lɔɡ/, depend /dɪˈpɛnd/, divide /dɪˈvaɪd/
- /æ/ — offener als „ä“: cache /kæʃ/, algorithm /ˈælɡəɹɪðm̩/, calculate /ˈkælkjʊleɪt/, calculation /ˌkælkjuˈleɪʃn̩/, hash /ˈhæʃ/
So übst du mit diesem Video
- Höre dir das ganze Video einmal an, ohne zu sprechen, und notiere die Wörter, die du nicht kennst.
- Beginne mit 0,75-facher Geschwindigkeit, sprich Satz für Satz nach und wechsle zur normalen Geschwindigkeit, sobald es leichtfällt.
- Nimm dich auf und vergleiche mit dem Original; achte dabei auf Wörter wie database, server, cache.
Was ist die Shadowing-Technik?
Shadowing ist eine wissenschaftlich fundierte Sprachlerntechnik, die ursprünglich für die professionelle Dolmetscherausbildung entwickelt und durch den Polyglotten Dr. Alexander Arguelles populär gemacht wurde. Die Methode ist einfach aber wirkungsvoll: Du hörst englisches Audio von Muttersprachlern und wiederholst es sofort laut — wie ein Schatten, der dem Sprecher mit nur 1–2 Sekunden Verzögerung folgt. Anders als passives Hören oder Grammatikübungen zwingt Shadowing dein Gehirn und deine Mundmuskulatur, gleichzeitig echte Sprachmuster zu verarbeiten und zu reproduzieren. Studien zeigen, dass es Aussprachegenauigkeit, Intonation, Rhythmus, verbundene Sprache, Hörverständnis und Sprechflüssigkeit signifikant verbessert — was es zu einer der effektivsten Methoden für die IELTS Speaking-Vorbereitung und reale englische Kommunikation macht.