A distributed system is a collection of separate computers that work together, appearing to its users as a single, coherent system. Think of it like a team of people working on one big project. Each person has their own computer and can work independently, but they communicate and coordinate to achieve a common goal. To an outsider, it just looks like the project is getting done; they don't see all the individual computers and messages flying back and forth.

These systems have a few defining characteristics. First, resources are shared. This could be anything from processing power and memory to data files and peripherals like printers. Second, the different parts of the system run at the same time, a concept known as concurrency. Finally, and most importantly, components can fail independently. One computer crashing doesn't necessarily bring down the entire system, which is a major reason for building them this way.

There are several ways to organize, or architect, a distributed system. Two of the most common patterns are client-server and peer-to-peer.

In this model, one or more central computers, called servers, hold the data or resources. Other computers, called clients, connect to these servers to request services or information. The server processes the request and sends a response back to the client. The roles are clearly defined: clients initiate requests, and servers fulfill them.

The peer-to-peer (P2P) model is different. There are no specialized servers. Instead, all computers in the network are considered equal, or peers. Each peer can act as both a client and a server, requesting information from some peers while providing it to others. P2P systems are often used for file sharing, where a file is broken into chunks and distributed across many different computers. When you download the file, you're actually pulling these chunks from multiple peers simultaneously.

Connecting computers over a network introduces challenges that don't exist when everything runs on a single machine. Two of the biggest hurdles are latency and network partitions.

Latency is the delay it takes for information to travel across the network. Think of a conversation with someone standing right next to you versus someone on the other side of the world via satellite phone. The local conversation is instant, but the satellite call has a noticeable lag. In distributed systems, this delay is always present. Even at the speed of light, it takes time for a message to travel from a server in New York to a user in Tokyo. System designers must account for this delay to ensure their applications feel responsive.

A network partition is more severe. This happens when the network breaks, splitting the system into two or more groups of computers that cannot communicate with each other. It's like a drawbridge opening in the middle of a city, separating it into two halves. Each side might continue to operate, but they have no idea what the other side is doing. This can lead to big problems, as different parts of the system might make conflicting decisions based on incomplete information.

Dealing with latency and the possibility of network partitions is what makes designing and building reliable distributed systems so challenging and interesting.