Course title: Introduction to Distributed Systems

Course code: ITec3102

Credit hours: ECTS: 5, Contact hrs: 2, Lab hrs: 3
Prerequisite - ITec2102, ITec2022

Course Description
• A distributed system is a computer system consisting of several
independent computers, connected by a network, that can work
together to perform a task or provide a service.
• Typical examples include: the WWW, networked file systems,
DNS, and massive multiprocessor supercomputers.
• In this course we will focus on the principles, techniques, and
practices relevant to the design and implementation of such
systems.
• The course takes a systems-oriented view of distributed systems,
concentrating on infrastructure software and providing hands-on
experience of implementing distributed systems.
 Course objectives
After completing this course, you will be able to:
• Explain what a distributed system is, why they would design a system as
a distributed system, and what the desired properties of such systems.
• List the principles underlying the functioning of distributed systems
describe the problems and challenges associated with distributed
systems, and evaluate the effectiveness and shortcomings of their
solutions.
• Recognize how the principles are applied in contemporary distributed
systems, explain how they affect the software design
• Design a distributed system that fulfills requirements with regards to key
distributed systems properties (such as scalability, transparency, etc.)
• Understand and exercise on distributed system software development
using basic OS mechanisms as well as higher-level middleware and
languages.
 Course outline
Chapter 1: Introduction Chapter 2: Architectures
1.1. Introduction 2.1 Introduction
1.2. Definition of DS 2.2 Architectural Styles
1.3. Goals of a DS 2.3 System Architectures
1.4. Types of DS

Chapter 3: Processes Chapter 4: Communication

3.1. Introduction to Threads 4.1. Layer protocols
3.2. Threads in DS 4.2. Types of Communication
3.3. Clients 4.3. Remote Procedure Call
3.4. Servers 4.4. Remote Object invocation
3.5. Code Migration
 Course outline
Chapter 5: Naming Chapter 6: Synchronization
5.1. Naming Entities 6.1. Overview
5.2. Flat Naming 6.2. Clock Synchronization
5.3. Structured Naming 6.3. Physical Clocks
5.4. Attribute based naming 6.4. Logical Clocks
Chapter 7: Consistency and Chapter 8: Fault Tolerance
Replication
7.1. Introduction to 8.1. Basic Concepts
Consistency 8.2. Failure Models
7.2. Reasons for Replication 8.3. Process Resilience
7.3. Replication as Scaling 8.4. Distributed Commit
Technique 8.5. Recovery
Introduction to Distributed Systems
Chapter 01: Introduction
Introduction From networked systems to distributed systems

Centralized vs Distributed vs Decentralized

What many people state

Centralized Decentralized Distributed

• Centralized: A system where one central server controls everything and all
clients depend on it.
- Structure: Clients → communicate only with → Central Server.
• Decentralized System: Multiple central authorities exist, but they operate
independently.
- Structure: Several central nodes → each controls its own part.
• Distributed System: A collection of independent computers that appear to
users as one single system.
- Structure: Several central nodes → each controls its own part.
Distributed versus decentralized systems
Introduction From networked systems to distributed systems

Alternative approach
Two views on realizing distributed systems
• Integrative view: connecting existing networked computer systems into a
larger a system.
• Expansive view: an existing networked computer systems is extended
with additional computers

Definitions
• A distributed system is a collection of independent computers that
work together and appear to users as a single coherent system.
• “… a system in which the failure of a computer you didn’t even
know existed can render your own computer unusable.” Leslie
Lamport
• multiple computers communicating via a network…
• trying to achieve some task together
• Consists of “nodes” (computer, phone, car, robot, …)
Distributed versus decentralized systems
Introduction From networked systems to distributed systems

Distributed System Middleware.

A distributed system organized as middleware. The middleware layer extends
over multiple machines, and offers each application the same interface.

Distributed versus decentralized systems

Introduction From networked systems to distributed systems

Some common misconceptions

Centralized solutions do not scale.
Make distinction between logically and physically centralized.
Physical centralization → one machine / one location
• Runs on a single server or site
• Single failure point
• Hard to scale and less resilient.

The root of the Domain Name System:

• logically centralized. (There is one global root namespace)
• physically (massively) distributed. many root server clusters worldwide.
• decentralized across several organizations.

Centralized solutions have a single point of failure

Generally not true (e.g., the root of DNS). A single point of failure is often:
• easier to manage
• easier to make more robust

Distributed versus decentralized systems

Introduction From networked systems to distributed systems

Perspectives on distributed systems

Distributed systems are complex: take persepctives
• Architecture: common organizations
• Process: what kind of processes, and their relationships
• Communication: facilities for exchanging data
• Coordination: application-independent algorithms
• Naming: how do you identify resources?
• Consistency and replication: performance requires of data, which need to
be the same
• Fault tolerance: keep running in the presence of partial failures
• Security: ensure authorized access to resources

Studying distributed systems

Introduction Design goals

What do we want to achieve?

Overall design goals of distributed system
• Support sharing of resources
• Distribution transparency
• Openness
• Scalability
Introduction Design goals

Sharing resources

A distributed system exists so multiple users and machines can access

and use shared things.
Resources can be:
• data (databases, files)
• hardware (printers, sensors, GPUs)
• services (authentication, storage, APIs)

Canonical examples
• Cloud-based shared storage and files
• Peer-to-peer assisted multimedia streaming (E.g. BitTorrent)
• Shared mail services (think of outsourced mail systems)
• Shared Web hosting (think of content distribution networks. E.g. Cloudflare)

Goal
“make remote resources feel accessible and usable across the network.”

Resource sharing
Introduction Design goals

Distribution transparency

What is transparency?
The phenomenon by which a distributed system attempts to hide the fact that
its processes and resources are physically distributed across multiple
computers, possibly separated by large distances.

Observation
Distribution transparancy is handled through many different techniques in a
layer between applications and operating systems: a middleware layer.

Distribution transparency
Introduction Design goals

Distribution transparency
Types

Transparency Description
Access Hide differences in data representation and how an
object is accessed
Location Hide where an object is located
Relocation Hide that an object may be moved to another location
while in use
Migration Hide that an object may move to another location
Replication Hide that an object is replicated
Concurrency Hide that an object may be shared by several
independent users
Failure Hide the failure and recovery of an object

Distribution transparency
Introduction Design goals

Degree of transparency
Aiming at full distribution transparency may be too much

Distribution transparency
Introduction Design goals

Degree of transparency
Aiming at full distribution transparency may be too much
• There are communication latencies and bandwidth that cannot be hidden
• Latency: time until message arrives
• In the same building/datacenter: ≈ 1 ms
• One continent to another: ≈ 100 ms
• Bandwidth: data volume per unit time
• 3G cellular data: ≈ 1 Mbit/s
• Home broadband: ≈ 10 Mbit/s

Distribution transparency
Introduction Design goals

Degree of transparency
Aiming at full distribution transparency may be too much
• There are communication latencies and bandwidth that cannot be hidden
• Latency: time until message arrives
• In the same building/datacenter: ≈ 1 ms
• One continent to another: ≈ 100 ms
• Bandwidth: data volume per unit time
• 3G cellular data: ≈ 1 Mbit/s
• Home broadband: ≈ 10 Mbit/s
• Completely hiding failures of networks and nodes is (theoretically and
practically) impossible
• You cannot distinguish a slow computer from a failing one
• You can never be sure that a server actually performed an operation
before a crash
• Full transparency will cost performance, exposing distribution of the
system
• Keeping replicas exactly up-to-date with the master takes time
• Immediately flushing write operations to disk for fault tolerance

Distribution transparency
Introduction Design goals

Degree of transparency
Exposing distribution may be good
• Making use of location-based services (finding your nearby friends)
• For example, showing nearby friends, local events, or regional data
sources is easier if the system exposes distribution rather than hides it.
• When dealing with users in different time zones: Awareness of
distribution allows applications to manage time-sensitive interactions
effectively.
• When it makes it easier for a user to understand what’s going on (when
e.g., a server does not respond for a long time, report it as failing).

Conclusion
Distribution transparency is a nice goal, but achieving it is a different story, and
it should often not even be aimed at.

Distribution transparency
Introduction Design goals

Openness of distributed systems

Open distributed system
→ An open distributed system is a distributed system designed to interoperate
easily with other systems.
→ It emphasizes openness, modularity, and integration.
→ An open distributed system itself will often consist of components that
originate from elsewhere.

What are we talking about?

Be able to interact with services from other open systems, irrespective of the
underlying environment:
• Systems should conform to well-defined interfaces
• Systems should easily interoperate
• Systems should support portability of applications
• Applications can be moved from one environment to another.
• Systems should be easily extensible
• Systems are designed to add new components or services easily.

Openness
Introduction Design goals

Policies versus mechanisms

Implementing openness: policies
• What level of consistency do we require for client-cached data?
• Which operations do we allow downloaded code to perform?
• E.g. Can downloaded code access local files, network resources, or only in-
memory data?
• Which QoS requirements do we adjust in the face of varying bandwidth?
• Decide QoS parameters to adjust when network conditions change.
• Example: Adjust video streaming resolution when bandwidth drops.
• What level of secrecy do we require for communication?

Implementing openness: mechanisms

• Allow (dynamic) setting of caching policies.
• E.g. Clients can 10s for real-time stock quotes, 1h for weather data.
• Support different levels of trust for mobile code, E.g. Sandbox untrusted code
• Provide adjustable QoS parameters per data stream
• Offer different encryption algorithms
Openness
Introduction Design goals

Dependability
Basics
A component provides services to clients. To provide services, the component
may require the services from other components ⇒ a component may depend
on some other component.

Requirements related to dependability

Requirement Description
Availability Readiness for usage (fraction of up-time)
Reliability Continuity of service delivery
Safety Very low probability of catastrophes
Maintainability How easy can a failed system be repaired

Dependability
Introduction Design goals

Availability
Availability: The system is operational and accessible when users need it.
In distributed systems: Because components are spread across multiple
nodes, failures are expected. Availability focuses on keeping the service
running despite those failures.

Limits to availability
• Frequency of system failures
– Redundancy can improve availability.
• Detection & repair time
– Detect, diagnose, repair failed component, restart the system
– Time to reconfigure to redundant standby.
• As a practical matter, 99.999% is considered “high availability”
– 99.999% “Five nines” ➔ ~5 minutes/year down time
– 99.9999% “Six nines” ➔ 31.5 seconds/year down time

Dependability
Introduction Design goals

Reliability
Definition: The system performs correctly and consistently over time.
In distributed systems: Messages can be delayed, lost, or duplicated. Reliability
ensures the system still produces correct results even with such issues.
Example: A banking system must process a transfer exactly once — not zero
times, not twice.

Other aspects of dependability

Safety: Failures must not lead to
dangerous states, corrupted data,
or incorrect critical decisions.
E.g. a failure must not display
false patient data.

Maintainability: The system can

be repaired, updated, and
improved efficiently.
E.g. 80% of failure can be fixed in
1 hour.

Dependability
Introduction Design goals

Terminology
Failure, error, fault

Term Description Example

Failure Is when system does not Crashed program,
provide required service incorrect output
Error Is an activated fault flipped bit is read and used
in a calculation
Fault Is something that goes wrong bit flip

Dependability
Introduction Design goals

On security
Observation
A distributed system that is not secure, is not dependable

Security
Introduction Design goals

On security
Observation
A distributed system that is not secure, is not dependable

What we need
• Confidentiality: information is disclosed only to authorized parties
• Integrity: Ensure that alterations to assets of a system can be made only
in an authorized way

Security
Introduction Design goals

On security
Observation
A distributed system that is not secure, is not dependable

What we need
• Confidentiality: information is disclosed only to authorized parties
• Integrity: Ensure that alterations to assets of a system can be made only
in an authorized way

Authorization, Authentication, Trust

• Authentication: verifying the correctness of a claimed identity
• Authorization: does an identified entity has proper access rights?
• Trust: one entity can be assured that another will perform particular
actions according to a specific expectation

Security
Introduction Design goals

Security mechanisms
Keeping it simple
It’s all about encrypting and decrypting data using security keys.

Notation
K (data) denotes that we use key K to encrypt/decrypt data.

Security
Introduction Design goals

Security mechanisms
Symmetric cryptosystem
With encryption key EK (data) and decryption key DK (data):
if data = DK (EK (data)) then DK = EK . Note: encryption and descryption key
are the same and should be kept secret.

Asymmetric cryptosystem
Distinguish a public key PK (data) and a private (secret) key SK (data).

Security
Introduction Design goals

Security mechanisms
Secure hashing
In practice, we use secure hash functions: H(data) returns a fixed-length
string.
• Any change from data to data∗will lead to a completely different string
H(data∗).
• Given a hash value, it is computationally impossible to find a data with
h = H(data)

Security
Introduction Design goals

Security mechanisms
Secure hashing
In practice, we use secure hash functions: H(data) returns a fixed-length
string.
• Any change from data to data∗will lead to a completely different string
H(data∗).
• Given a hash value, it is computationally impossible to find a data with
h = H(data)

Practical digital signatures

Sign message for Bob by Alice:

Security
Introduction Design goals

Scale in distributed systems

• Scaling distributed systems is essential for handling growing demands and
ensuring performance.
• Scalability of a system is measured with respect to:
1. Size - Can easily add more users and resources to the system.
2. Geographic extent - A geographically scalable system is one in which
the users and resources may lie far apart.
3. Administrative scalability - can be easy to manage even if it spans
many independent administrative organizations.

Problems with scalability in distributed systems

• Synchronization communication: Currently hard to scale existing
distributed systems designed for local-area networks.
• Communication between two machines in LAN is generally at worst a
few hundred microseconds.
• In a wide-area system, inter-process communication may be hundreds
of milliseconds, three orders of magnitude slower.
• Unreliability of Communication: Communication in wide-area networks is
inherently unreliable
Scalability
Introduction Design goals

Techniques for scaling

There are two ways to do this

Vertical scaling (scaling up), Adding more resources to existing nodes

(servers) in the system. This typically involves increasing the CPU power,
RAM, or storage capacity of individual servers.

Horizontal scaling (scaling out), Adding more nodes (servers) to the system.
This involves horizontally increasing the number of servers working together.
• There are now basically three techniques for scaling out to be considered:
▪ Hiding communication latencies.(Shipping code)
▪ Distribution.
▪ Replication.

Scalability
Introduction Design goals

Techniques for scaling

Hiding communication latencies: is important to achieving geographical
scalability.

❑ Try to avoid waiting for responses to remote service requests.

▪ When a service has been requested at a remote machine, an
alternative to waiting for a reply from the server is to do other useful
work at the requester's side.
▪ Construct the requesting application in such a way that it uses only
Asynchronous communication.
❑ Reduce the overall communication
▪ E.g. in interactive applications when a user sends a request he will
generally have nothing better to do than to wait for the answer.
▪ Move part of the computation that is normally done at the server to the
client process requesting the service.
▪ Typical case - Accessing databases using forms.

Scalability
Introduction Design goals

Techniques for scaling

Facilitate solution by moving computations to client
Ship the code for filling in the form, and possibly checking the entries, to the
client, and have the client return a completed form

The difference between letting (a) a server or (b) a client check forms as they
are being filled.
Scalability
Introduction Design goals

Techniques for scaling

Distribution: Splitting a component into smaller parts and spreading those parts
across the system.
• Move computations to clients (Java applets and scripts)
• Decentralized naming services (DNS)
• Decentralized information systems (WWW)
E.g. Internet Domain Name System (DNS).
• The DNS name space is hierarchically organized into a tree of domains, which
are divided into no overlapping zones
• Names in each zone are handled by a single name server.
• Resolving a name means returning the network address of the associated host

Scalability
Introduction Design goals

Techniques for scaling

• E.g. the name [Link].
• To resolve this name - first passed to the server of zone Z1 which returns the
address of the server for zone Z2, to which the rest of name, [Link], can be
handed.
• The server for Z2 will return the address of the server for zone Z3, which is capable
of handling the last part of the name and will return the address of the associated
host.

Scalability
Introduction Design goals

Techniques for scaling

Replication and caching: Make copies of data available at different machines.
• Replicated file servers and databases
• Mirrored Web sites
• Web caches (in browsers and proxies)
• File caching (at server and client)
Replication.
• Increases availability
• Helps balance the load between components leading to better performance.
• e.g. in geographically widely-dispersed systems - a copy nearby can hide much
of the communication latency problems.
Caching - special form of replication
N.B. Caching happens on demand whereas replication is often planned in
advance.

Scalability
Introduction A simple classification of distributed systems

Three types of distributed systems

► High performance distributed computing systems

▪ Parallel Computing, cluster Computing, grid Computing
► Distributed information systems
► Distributed systems for pervasive computing

High-performance distributed computing

Introduction A simple classification of distributed systems

Parallel computing
Observation
▪ High-performance distributed computing started with parallel computing.
▪ Designed for high-performance computing, these systems use multiple
computers to solve a single, complex, or compute-intensive task.
▪ They often use cluster computing (homogeneous, fast local network) or
grid computing (heterogeneous, often wide-area) to process large
datasets or perform parallel computing.

Multiprocessor and multicore versus multicomputer

High-performance distributed computing

Introduction A simple classification of distributed systems

Distributed shared memory systems

Observation
Multiprocessors are relatively easy to program in comparison to multicomputers,
yet have problems when increasing the number of processors (or cores).
Solution: Try to implement a shared-memory model on top of a multicomputer.

Example through virtual-memory techniques

Map all main-memory pages (from different nodes) into one single virtual address
space. If a process at processor(node) A addresses a page P located at
processor(node) B, the OS at A traps and fetches P from B, just as it would if P
had been located on local disk.

Problem
Performance of distributed shared memory could never compete with that of
multiprocessors, and failed to meet the expectations of programmers. It has
been widely abandoned by now.

High-performance distributed computing

Introduction A simple classification of distributed systems

Cluster computing
Essentially a group of high-end systems connected through a LAN
• Homogeneous: same OS, near-identical hardware
• Single, or tightly coupled managing node(s)

High-performance distributed computing

Introduction A simple classification of distributed systems

Grid computing
The next step: plenty of nodes from everywhere
• Heterogeneous
• Dispersed across several organizations
• Can easily span a wide-area network

Note
To allow for collaborations, grids generally use virtual organizations. In essence,
this is a grouping of users (or better: their IDs) that allows for authorization on
resource allocation.

High-performance distributed computing

Introduction A simple classification of distributed systems

Architecture for grid computing

The layers
• Fabric: Provides interfaces to local
resources (for querying state and
capabilities, locking, etc.)
• Connectivity: Communication/transaction
protocols, e.g., for moving data between
resources. Also various authentication
protocols.
• Resource: Manages a single resource,
such as creating processes or reading
data.
• Collective: Handles access to multiple
resources: discovery, scheduling,
replication.
• Application: Contains actual grid
applications in a single organization.

High-performance distributed computing

Introduction A simple classification of distributed systems

Integrating applications (Distributed IS integration)

Situation
Organizations confronted with many networked applications, but achieving
interoperability was painful.
E.g. Large organizations accumulated separate applications over time:
• HR system
• Payroll system
• Inventory database
Each one was built at a different time, used different data formats, or ran on
different platforms

Basic approach
A networked application is one that runs on a server making its services available to
remote clients. Simple integration: clients combine requests for (different)
applications; send that off; collect responses, and present a result to the user.
Example workflow: Ask HR for employee info, Ask payroll for salary, Ask finance
for project cost, Combine into one report.

Next step: Allow direct application-to-application communication, leading to

Enterprise Application Integration.
Distributed information systems
Introduction A simple classification of distributed systems

Example EAI: (nested) transactions

Transaction
Primitive Description
BEGIN TRANSACTION Mark the start of a transaction
END TRANSACTION Terminate the transaction and try to commit
ABORT TRANSACTION Kill the transaction and restore the old values
READ Read data from a file, a table, or otherwise
WRITE Write data to a file, a table, or otherwise

Issue: all-or-nothing
• Atomic: happens indivisibly (seemingly)
• Consistent: does not violate system invariants
• Isolated: not mutual interference
• Durable: commit means changes are permanent

Distributed information systems

Introduction A simple classification of distributed systems

TPM: Transaction Processing Monitor

Observation
Often, the data involved in a transaction is distributed across several servers. A
TP Monitor is responsible for coordinating the execution of a transaction.

Distributed information systems

Introduction A simple classification of distributed systems

Middleware and EAI

Middleware offers communication facilities for integration

Remote Procedure Call (RPC): Requests are sent through local procedure
call, packaged as message, processed, responded through message, and
result returned as return from call.
Message Oriented Middleware (MOM): Messages are sent to logical contact
point (published), and forwarded to subscribed applications.

Distributed information systems

Introduction A simple classification of distributed systems

How to integrate applications

File transfer: Technically simple, but not flexible:

• Figure out file format and layout
• Figure out file management
• Update propagation, and update notifications.
Shared database: Much more flexible, but still requires common data scheme
next to risk of bottleneck.
Remote procedure call: Effective when execution of a series of actions is
needed.
Messaging: RPCs require caller and callee to be up and running at the same
time. Messaging allows decoupling in time and space.

Distributed information systems

Introduction A simple classification of distributed systems

Distributed pervasive systems

Observation
Emerging next-generation of distributed systems in which nodes are small,
mobile, and often embedded in a larger system, characterized by the fact that
the system naturally blends into the user’s environment.

Three (overlapping) subtypes

Pervasive systems
Introduction A simple classification of distributed systems

Distributed pervasive systems

Observation
Emerging next-generation of distributed systems in which nodes are small,
mobile, and often embedded in a larger system, characterized by the fact that
the system naturally blends into the user’s environment.

Three (overlapping) subtypes

• Ubiquitous computing systems: pervasive and continuously present, i.e.,
there is a continuous interaction between system and user.

Pervasive systems
Introduction A simple classification of distributed systems

Distributed pervasive systems

Observation
Emerging next-generation of distributed systems in which nodes are small,
mobile, and often embedded in a larger system, characterized by the fact that
the system naturally blends into the user’s environment.

Three (overlapping) subtypes

• Ubiquitous computing systems: pervasive and continuously present, i.e.,
there is a continuous interaction between system and user.
• Mobile computing systems: pervasive, but emphasis is on the fact that
devices are inherently mobile.

Pervasive systems
Introduction A simple classification of distributed systems

Distributed pervasive systems

Observation
Emerging next-generation of distributed systems in which nodes are small,
mobile, and often embedded in a larger system, characterized by the fact that
the system naturally blends into the user’s environment.

Three (overlapping) subtypes

• Ubiquitous computing systems: pervasive and continuously present, i.e.,
there is a continuous interaction between system and user.
• Mobile computing systems: computation on movement, but emphasis
is on the fact that devices are inherently mobile.
• Sensor (and actuator) networks: pervasive, with emphasis on the actual
(collaborative) sensing and actuation of the environment.

Pervasive systems
Introduction A simple classification of distributed systems

Sensor (and actuator) networks in smart agriculture

Pervasive systems
Introduction A simple classification of distributed systems

Ubiquitous systems
Core elements
1. (Distribution) Devices are networked, distributed, and accessible
transparently
2. (Interaction) Interaction between users and devices is highly unobtrusive
3. (Context awareness) The system is aware of a user’s context to optimize
interaction
4. (Autonomy) Devices operate autonomously without human intervention,
and are thus highly self-managed
5. (Intelligence) The system as a whole can handle a wide range of dynamic
actions and interactions

Pervasive systems
Introduction A simple classification of distributed systems

Mobile computing
Distinctive features
• A myriad of different mobile devices (smartphones, tablets, GPS devices,
remote controls, active badges).
• Mobile implies that a device’s location is expected to change over time ⇒
change of local services, reachability, etc. Keyword: discovery.
• Maintaining stable communication can introduce serious problems.
• For a long time, research has focused on directly sharing resources
between mobile devices. It never became popular and is by now
considered to be a fruitless path for research.

Bottomline
Mobile devices set up connections to stationary servers, essentially bringing
mobile computing in the position of clients of cloud-based services.

Pervasive systems
Introduction A simple classification of distributed systems

Mobile computing

Mobile cloud computing

Mobile edge computing

Pervasive systems
Introduction A simple classification of distributed systems

Sensor networks
Characteristics
The nodes to which sensors are attached are:
• Many (Scalability is non-negotiable)
Protocols must work whether there are 20 or 2,000 nodes.
• Simple (small memory/compute/communication capacity)
Each node is intentionally minimal — tiny CPU, tiny RAM, low-power radio.
• Often battery-powered (or even battery-less)

Pervasive systems
Introduction A simple classification of distributed systems

Sensor networks as distributed databases

Two extremes

Centralized Processing: All sensor data is sent directly to an operator's site for
storage and analysis.
Distributed Processing: Each individual sensor has the power to process and
store its own data. In this model, the operator sends a query to the network, and
the sensors send back only the specific answers needed.
Pervasive systems
Introduction A simple classification of distributed systems

The cloud-edge continuum

Pervasive systems
Introduction Pitfalls

Developing distributed systems: Pitfalls

Observation
Many distributed systems are needlessly complex, caused by mistakes that
required patching later on. Many false assumptions are often made.

False (and often hidden) assumptions

• The network is reliable
• The network is secure
• The network is homogeneous
• The topology does not change
• Latency is zero
• Bandwidth is infinite
• Transport cost is zero
• There is one administrator