Shadowing Practice: Distributed Systems 1.1: Introduction - Learn English Speaking with Video

Hello everybody, my name is Martin Kleppmann and I'm going to be giving the next eight lectures on distributed systems.

This is the second half of the course on concurrent and distributed systems.

And so in the first half of this course, you've seen a lot on concurrency that occurs within a single process.

So when you have, especially when you have multiple threads within a single process that are performing operation concurrently, will ensuring safe concurrency.

In this kind of concurrent system, you have all of the threads usually sharing a single address space.

And so you can just pass a variable from one thread to another thread, and that variable can contain pointers or references to arbitrary objects,

and this will work because the memory addresses

that one thread can access are the same as the memory addresses that another thread can access.

Now, when we move to distributed systems, this changes.

So in distributed systems, we still have concurrency.

We still have multiple processes and multiple threads performing operations concurrently, potentially.

But we also have the additional challenge that now we're talking about not just a single program running on a single computer,

but multiple programs running on multiple computers where those computers are communicating via a network.

And this aspect that we are now introducing this network is part of what makes a distributed system distributed.

Another aspect is also that we don't have a single shared address space anymore.

So a pointer that makes sense in one process, if you send it over the network to another process running on a different computer,

that pointer will not necessarily make any sense to the recipient of that message,

And so we have to think about different ways of sharing data between these concurrent entities.

So, um, A definition of a distributed system, a somewhat joking definition provided by Leslie Lamport,

is that a distributed system is a system in

which the failure of a computer you didn't even know existed can render your own computer unusable.

Whether this is a good definition or not, we can debate, but Leslie Lamport is a bit of a legend in the area of distributed systems,

and we will see various aspects of work that he's done over the decades.

and of course lots of other people have done work in this area, and we will see that over the course of these lectures.

So more generally I think I would define a distributed system as one

in which you have got multiple computers or computing devices.

devices might be smartphones, they might be robots, they might be self -driving cars, they might be desktop computers, they might be servers in a data center.

So any sort of computing device really.

And these computing devices are communicating via some kind of network, which might be the internet, and they are trying to achieve some kind of task together.

And the study of distributed systems is really the study of

how do we coordinate the activities of these different devices in such a way

that they achieve together the task that they are trying to achieve.

So I will start with a little bit of background first, just the administrative things to get that done.

First of all, if you want any further background reading on this course, hopefully the lecture notes will be reasonably self -contained,

but of course further detail is available in books if you're interested.

There are several different styles of books that I've put here on the list.

So the textbook by Van Steen and Tannenbaum, is a sort of systems level overview.

So this is, it comes at distributed systems from quite an applied angle of real applications that real people use and

discusses how these work and discusses the various implementation details of it.

It doesn't go as far into the theory as some of the other books and But it's more practically oriented.

If you like the theory, then the second book on this list is a good choice.

So the textbook by Kershin, Gerari, and Rodriguez is an excellent but quite detailed overview of distributed systems theory.

So it goes into a lot more depth than we have time to talk about in this course.

But if you want to read more about the theory, this is an excellent book.

I also wrote a book in this area called Designing Data Intensive Applications.

This book is a bit more oriented towards distributed database systems, so it's not just not just distributed systems in general,

there's a lot of other databases content in there, and this book is more oriented towards industrial software engineers.

So people who are working professionally with distributed databases will probably find this kind of useful.

And finally, there's the Bacon and Harris textbook, which was already recommended for the concurrent systems part of this course

which really provides the link between operating systems and distributed systems.

Okay, so this course is also connected to various other courses in the TRIPOS, most obviously concurrent systems that this course is part of,

also operating systems which you studied last year.

So all of the background that you had there on processes and inter -process communication and scheduling processes, all of that stuff is relevant for this course.

Also the databases course is connected to distributed systems because as I mentioned just now, Many modern databases are in fact distributed

and they use a lot of the techniques that we will talk about in this course.

So using modern databases often involves using distributed systems as well.

There's a strong connection between distributed systems and computer networking because as I said, distributed systems involve network communication generally.

The difference between the two courses is

that the computer networking course is mostly about how do you

actually get the bytes over the wire from one device to the other device.

So what do the network protocols look like that enable devices to communicate?

and then distributed systems builds on top of computer networking and saying, okay, assuming we now have this mechanism for devices to communicate,

how can we now ensure that these devices behave in the ways that we want?

So, There's connection to further Java, so there's programming exercises, that involve a bit of distributed computing.

The security aspects of distributed systems are very interesting

and they are covered in a course in Easter Term that's dedicated just to the topic of security.

And finally, next year's cloud computing course, builds upon distributed systems because cloud computing is all about

being able to flexibly process large amounts of data and if you have sufficiently large amounts of data,

you generally need a distributed system in order to process it.

Thank you.

Okay, so I gave a brief definition of what a distributed system is.

The next question is then why?

Like why should we go to all of this effort of making a system distributed.

Why can't we just use a single computer and keep things simple?

And well, one reason is that some applications, some types of things you want to do, computers are inherently distributed.

So if you want to send a message from your phone to your friend's phone, this inevitably involves two different phones and a network.

So this is a distributed system.

There's no way around it.

There's no way of building a messaging system that is not distributed.

if you want to be able to communicate across different devices.

And so building this type of software is one reason why we might be interested in distributed systems, but there are many other reasons as well.

So another good reason for being interested in distributed systems is that it actually allows us to make systems more reliable.

And the reason for this is say you have multiple computers which are each performing part of some some job.

If one of those fails, maybe one of them has to be rebooted for example, or one of them has a hardware failure,

about the work from the failed computer, and

so now this allows the system as a whole to continue

functioning even though one of the computers involved in it has actually gone down.

Another reason we might want to make systems distributed is for better performance.

So for example, in internet distributed systems, you might have users all around the world.

You might have some users in the UK, some users in the US, some users in New Zealand, some users in South Africa, wherever.

There are large distances between these different places, and so network communication from one of these places to the others is always going to take a little while.

uh you know you're talking at least 100 milliseconds uh

simply because of the speed of light that it takes for communication to travel from one continent to another.

And so one reason why people are interested in distributed systems is to make

systems faster by putting data closer to where the people are.

So if you have some users in multiple different continents, you can have computers in multiple different continents.

And if you have each user communicating with the computer that is most local to them,

then you avoid the long -distance intercontinental communication as part of the delays that are added to their communication.

So making systems distributed allows us to make them faster,

100

Another reason why people build distributed systems is to solve bigger problems than they could with a single computer.

101

So some computing problems are simply very large scale.

102

So think of scientific computing examples like,

103

for example, the CERN at the particle accelerator in Switzerland that includes the Large Hadron Collider,

104

they have a vast computing infrastructure involving a million CPU cores and God knows how many hard disks,

105

in order to just take all of the data

106

that they're gathering from the particle accelerator and process it and analyze it and try to

107

use this to discover new particles for example.

108

Now

109

this scale of task would simply not be possible to achieve on a single computer

110

because there is no supercomputer that is big enough to be able to handle these vast volumes of data.

111

simply solving this problem of analyzing such large volumes of data

112

has to be done on a network of lots of small computers

113

and and those computers have to distribute the work amongst them, and they have to work together in order to achieve the tasks that the scientists are trying to do.

114

This is really another key area in which we can use distributed systems is to solve bigger problems.

115

Now, those are the advantages of making systems distributed.

116

There are unfortunately some significant disadvantages as well.

117

And the main disadvantage that you will be well familiar with is whenever you're trying to do something over a network, that network might not be working for some reason.

118

And so everyone has experienced what it's like for the internet to be down

119

or for your Wi -Fi signal to be weak.

120

or for some rural part of the country

121

and your cellular data signal is weak and you're trying to load a map or something like that.

122

Everyone has experienced this kind of frustration before.

123

Well, the study of distributed systems is all about the study of such frustrations.

124

So, We assume whenever we are building a distributed system, that involves communication over a network, that networks are not perfectly reliable.

125

And so it is always possible for communication to fail.

126

It is always possible that because because if it's a wi -fi network you might be out of range,

127

if it's a wired network somebody might have unplugged the wrong cable, If it's any type of network, it might just be temporarily overloaded,

128

and so it might be dropping messages.

129

Maybe even somebody might be maliciously trying to interfere with the network, and cause it to drop packets, maybe causing a denial of service attack, for example.

130

There are many reasons why communication might not work from time to time.

131

And so we have to build systems that are robust so that even if communication is interrupted from time to time,

132

the system as a whole still functions in some correct way.

133

Where, of course, we can define what we mean with "correct", but we want it to continue functioning.

134

Another thing that can go wrong in distributed systems is that some of the processes, the running the code might crash and For example,

135

if you have a system consisting of multiple computers and you reboot one of them,

136

you probably want the remaining computers to carry on the task of serving user requests.

137

What we want here is that one of the processes is temporarily out of action, and we want the system as a whole to still continue nevertheless.

138

And finally, all of these failures can happen non -deterministically.

139

That is, we simply don't know when they happen.

140

They could happen at any moment, unpredictably, and we still have to ensure that the software works nevertheless.

141

So what we often strive for in distributed systems is what is known as fault tolerance

142

which means that even if some part of the system is faulty, some part of the system is not working,

143

the system as a whole still continues providing the service to the users.

144

This is one of the main challenges in distributed systems: how do we make things in such a way

145

that they can tolerate faults?

146

In fact, making things

147

distributed and fault tolerant is so difficult

148

that a lot of people who work professionally on distributed systems think

149

that oh well if you can solve a problem on a single computer it's basically easy so

150

if you can solve a problem on a single computer you'll

151

probably have a much better time just keeping it on one

152

computer not over complicating things not going into a distributed system setting and so All of the problems,

153

this Pandora's box of problems that arise with distributed systems, well, we should try and open that only if we actually have to.

154

But as we said earlier, there are lots of good reasons why you might have to open that box.

What is the Shadowing Technique?

Shadowing is a science-backed language learning technique originally developed for professional interpreter training and popularized by polyglot Dr. Alexander Arguelles. The method is simple but powerful: you listen to native English audio and immediately repeat it out loud — like a shadow following the speaker with just a 1–2 second delay. Unlike passive listening or grammar drills, shadowing forces your brain and mouth muscles to simultaneously process and reproduce real speech patterns. Research shows it significantly improves pronunciation accuracy, intonation, rhythm, connected speech, listening comprehension, and speaking fluency — making it one of the most effective methods for IELTS Speaking preparation and real-world English communication.

Shadowing Practice: Distributed Systems 1.1: Introduction - Learn English Speaking with Video

Context & Background

Top 5 Phrases for Daily Communication

Step-by-step Shadowing Guide

What is the Shadowing Technique?