Lesson 02:

Distributed System
Patterns
​Phillip J. Windley, Ph.D.
​CS462 – Large-Scale Distributed Systems
Lesson 02: Distributed System Patterns

Contents

00 Coupling
03 Distributed Architectures

01 04
Distributed System Design Axes Conclusion

02 Rethinking Distributed
Coupling ​One of the most important
properties of a distributed
system is how tightly or
loosely coupled the
processing is.
Lesson 02: Distributed System Patterns

Coupling

​Coupling refers to the degree to which two or more

processes are interdependent.
​We say two things are tightly coupled when they are
interdependent and loosely coupled when they are independent.
​Tight and loose coupling are not binary positions, but rather
relative terms. Any given architectural choice might make two
processes more or less coupled.

​CS462 – Large-Scale Distributed Systems 4

Lesson 02: Distributed System Patterns
Distributed Systems and
Loose Coupling
​Generally when designing
distributed systems
anything that makes the
system more loosely
coupled is desirable.
​But, no useful software
system can be built where
all the components are
completely decoupled.
​CS462 – Large-Scale Distributed Systems
If two processes are completely independent they can successfully
operate without any kind of coordination with the other process.
​Whenever we introduce dependencies, the processes must
coordinate their activities. This requires some kind of
communication between the two processes. This can result in
wasted computation, delays due to latency, and computational
errors.
​Of course, we can’t accomplish most interesting computations
without some coupling. Good distributed architectures accomplish
their tasks with a minimum of coupling. Good distributed system
architects choose architectures that minimize the coupling
necessary to get the job done.
5
Lesson 02: Distributed System Patterns

System Level Coupling

​Coupling can occur on multiple levels within a system. The following table gives some of
the choices that can be made at different levels of a system that increased or decrease
the level of coupling.

Level More Tightly Coupled More Loosely Coupled

Physical connection Direct Intermediary

Communication style Synchronous Asynchronous

Type system Strong type system Weak type system

Interaction pattern Remote procedure call Messages

Process logic control Central design Independent teams

Data schema Normalized Denormalized

Service discovery/binding Static Dynamic

Platform dependencies Dependent/specified Independent/guided

​Adapted from Enterprise SOA: Service-Oriented Architecture Best Practices

​CS462 – Large-Scale Distributed Systems 6

Lesson 02: Distributed System Patterns
Types of Coupling - Logical
​In Event-Based
Programming, Ted Faison
identifies three flavors of
coupling: logical, type, and
signature.
​CS462 – Large-Scale Distributed Systems
​Logical coupling occurs when two processes share information or
make assumptions about the other. When this happens, one
process can have an effect on the other even when they share no
data.
​For example, suppose both processes share an algorithm for
calculating sales tax. Changes to one process will affect the other
despite the fact that there is no computational artifact (code, API,
etc.) that links them. This can occur even if one makes assumptions
about how the other computes sales tax.
​Logical coupling can be and should be avoided because it adds
nothing to the computation and is a potential source of logical
errors and system failure.
7
Lesson 02: Distributed System Patterns
Types of Coupling - Type
​Type coupling occurs when
one process references
the external interface or
(worse) internal model of
another.
​CS462 – Large-Scale Distributed Systems
​Type coupling is one of the most common forms of coupling in
distributed systems. External interfaces abound and distributed
systems use those interfaces to make requests of and give
commands to other processes.
​External interfaces, called APIs, provide a contract that defines the
interprocess communication. Coupling occurs because the calling
process has to know the syntax and semantics of the API and is
thus dependent on it.
​Another, more insidious, form of type coupling occurs when
processes share a data model. For example two processes may
have direct access to a database and used it as a shared memory,
linking them. Shared memory requires careful and complex
coordination and is often a source of logical coupling through
share semantics.
8
Lesson 02: Distributed System Patterns

Types of Coupling - Platform

​Platform coupling is a special case of type coupling. Platforms

include not only popular language platforms like the Java JVM and
the .Net CLR, but also frameworks for other languages. Platforms
create coupling through common components and assumed or
defined interface patterns.
​This kind of coupling can provide advantages in the form of
reduced programming effort and abstractions to common
interaction patterns.
​But relying on platforms to solve interaction patterns also limits the
kinds of processes that can participate. As an example, if you build
a distributed system on the JVM and use RMI for interprocess
communication, processes implemented in non-JVM-based
languages can’t easily interact with the system as first-class
citizens.

​CS462 – Large-Scale Distributed Systems 9

Lesson 02: Distributed System Patterns
Types of Coupling - Signature
​Signature coupling occurs
when one process
indirectly and dynamically
causes another process to
take action.*
​* Faison defines signature coupling relative
to object-oriented programming. I’ve recast it
in light of more general-purpose distributed
system concepts.
​CS462 – Large-Scale Distributed Systems
​For distributed systems, the primary difference between type and
signature coupling is that the latter refers to run-time
considerations. For example, a service you depend on may be
down or non-performant.
​Messaging interfaces are also a form of signature coupling since
they are more dynamic than request-response or RPC-style
interfaces. Messages don’t require the same level of interface
dependency as an API.
​In general, signature coupling is preferable to type coupling since
two processes coupled by messaging know much less about the
internal semantics and capabilities of the other. Dynamic
interaction also allows for programmatic self-healing of faults, a
desirable property of distributed systems.
10
Design Axes ​The term distributed system
can refer to systems with
vastly different design
choices.
Lesson 02: Distributed System Patterns
Distributed Systems Use Many
Processes
​Distributed systems are
made from two or more
processes that are
interconnected to achieve
a specific purpose.
​Design involves choosing
the process architecture,
their interconnections,
and controlling data.
​CS462 – Large-Scale Distributed Systems
​We saw in Why Distributed Systems?[01] that a distributed system
is one made up of a number of processes that are coordinating
their efforts to achieve a specific goal or offer a specific service.
​The key principle is that even though multiple processes are being
used, to the end user of the computation, it appears that a single
computer were being used.
​Achieving this requires careful design. There are myriad design
choices a distributed system architect can follow in achieving
precise system goals.
12
Lesson 02: Distributed System Patterns

Where is the processing done?

​What do we mean by process? We’ve been circumspect to

this point, merely referring to processes. A process can be
many things.
​A process might be an entire CPU in an embedded system with a
simple, single-threaded OS. A process might be an OS process or
thread. And of course, they can be further virtualized by things like
hypervisors or the Java Virtual Machine (JVM).
​Processes can be running next to each other on the same CPU, on
different cores on the same chip, or spread out across machines in
the same data center or around the world.

​CS462 – Large-Scale Distributed Systems 13

Lesson 02: Distributed System Patterns

How are processes interconnected?

​Put another way what is the topology of the distributed

system?
​We can arrange the processing so that it flows along a pipeline of
processes. We can have have a central controller yielding a star
topology. We can arrange processing in a stack where
communication flows up and down. We might create a hierarchy or
tree. We can fully connect each of the processes so that they can
all speak together.
None of these are inherently better than the others. The best
choice depends on the problem that you’re solving.

​CS462 – Large-Scale Distributed Systems 14

Lesson 02: Distributed System Patterns

What is the communication style?

​There are numerous ways that processes can exchange

information. Each has implications for scalability, reliability,
and maintainability of the system.
​RPC, or remote procedure call, is the most straightforward, but
creates tight coupling that can affect system performance and
code understandability.
​Request-response is the primary communication style of the Web
and it’s underlying HTTP protocol. Request-response is typically
synchronous. Request-response and RESTful are often treated as
synonymous, but we’ll see they’re different.
​Messaging is the most general and can be synchronous or
asynchronous. Events are special types of messages that notify of
a state change.

​CS462 – Large-Scale Distributed Systems 15

Lesson 02: Distributed System Patterns

Where is information stored?

​Distributed systems are significantly simpler when they

don’t have to worry about state or information storage. Of
course, most interesting systems have state.
​Parallel processing achieves impressive performance by carefully
managing where information is stored and when. In addition, many
parallel processing processes are stateless.
​Google, Facebook, and other large systems split stored information
into logical chunks (called sharding) and route requests to the
process with the right chunk.
​Microservice architectures denormalize data to locate it with the
processes that use it.
​Poor information management leads to poor performance and tight
coupling.

​CS462 – Large-Scale Distributed Systems 16

 ​The common nomenclature

Rethinking for relating distributed and

decentralized computing is
limited. Let’s redefine it.

Distributed
Lesson 02: Distributed System Patterns

Centralized, Decentralized, &

Distributed

​Traditionally centralized, decentralized, and distributed topologies have been arranged

linearly as shown above. Occasionally you’ll see distributed and decentralized swapped.
​This section presents a different view of these important concepts.

​CS462 – Large-Scale Distributed Systems 18

Lesson 02: Distributed System Patterns

Distributed Doesn’t Belong with

Centralized

​A better way to think about the

categorization is to use different axes.
​Centralized and decentralized are opposites,
indicating the degree to which the components
are under the control of a single entity or multiple
entities. A central control point could be logical or
abstract so long as it is able to effectively
coordinate nodes in the system.
​The second axis measures the degree to which
the components are co-located or distributed. Co-
location could be either physical or logical
depending on the context and level of
abstraction.

​CS462 – Large-Scale Distributed Systems ​ 19

Lesson 02: Distributed System Patterns
Introducing Heterarchy
​Hierarchy is a familiar
word that is used
frequently to describe
different kinds of
organization.
​Heterarchy refers to a
related, familiar concept,
even if it is an unfamiliar
word.
​CS462 – Large-Scale Distributed Systems
​Hierarchy is an arrangement of items where any given item can
be above or below others. Hierarchy depends on ranking and
invokes concepts such as superior, inferior, subordinate, order,
rank, and level.
​In contrast, a heterarchy is an arrangement where items are not
ranked and all, theoretically, play an equal role—they are peers.
Peers in a heterarchy may be related and connected to each
other in different ways.
​Most interesting systems, like social and biological systems, are
mixtures of hierarchy and heterarchy. For example, cities are
largely heterarchical in organization, but contain many
hierarchical structures, including the city government,
businesses, and families.
20
Lesson 02: Distributed System Patterns

A Third Way to Classify

​Computer processes can be arranged

hierarchically or heterarchically.
​Heterarchical and hierarchical are different than
distributed, co-located, centralized, or
decentralized, providing a third axis in our
classification matrix.
​Computer systems can be centralized and yet
heterarchical (e.g. Facebook’s OpenGraph
model) or decentralized and yet hierarchical (e.g.
DNS). We’ll explore these concepts more in
future lessons.

​CS462 – Large-Scale Distributed Systems 21

Lesson 02: Distributed System Patterns

Heterarchical Computing

​Computing processes can ​Heterarchical organization of a distributed system depends on

processes that are not hard wired for a particular function.
be arranged as peers, in a Different nodes in the computation should be able to perform
heterarchy. different functions depending on what needs done.
​Heterarchy also requires the freedom to bypass. Specifically, if the
connections between the nodes make some nodes intermediaries
or gatekeepers, then the nodes in the system cannot perform as
peers. Any intermediaries must be transparent to the participants
in the computation.
​Heterarchical systems are sometimes called peer-to-peer or fully-
connected.

​CS462 – Large-Scale Distributed Systems 22

Interconnection ​The way processes
communicate has a big

Patterns
impact on performance,
reliability, and scalability.
Lesson 02: Distributed System Patterns

Pipelines and Trees

​Parallel computation performs the same operations on

similarly structured data. Processes performing these
operations have limited, structured communication needs.
​Parallel computation thus lends itself to process organization as
some form of tree or pipeline. Super computers and big data
computations are usually organized as pipelines or trees.
​If you’ve played with UNIX pipes and filters, you probably realize
that many of the filters can execute concurrently (although they
often don’t) to quickly achieve the desired result.

​CS462 – Large-Scale Distributed Systems 24

Lesson 02: Distributed System Patterns

Client-Server

​One of the most widely used distributed architectures is

the client-server architecture. Mobile computing is the
latest invocation of this model.
​The server is accessed by many remotely-located clients. The
server provides access to resources like data and processing. The
server is often responsible for application workflow and the model
integrity of that workflow.
​The client may do very little processing, called thin-client, or may be
responsible for the bulk of the application logic, called thick-client.
​A weather app, for example, may be primarily about display and
some user interaction. The hard work of producing the weather
forecast done somewhere else.
​A camera app, on the other hand, is doing most of the work on the
local machine with only ancillary remote interactions.

​CS462 – Large-Scale Distributed Systems 25

Lesson 02: Distributed System Patterns

Multi-Tiered Architecture

​Multi-tiered architectures are an extension of the

Browser
client-server model, expanding the server into
distributed parts.
​The tiers represent key components the model-view-controller Presentation Tier API
model, which each part having it’s own layer.
​The processes in each tier can be optimized and configured for a specific task.
The computers supporting them can be sized differently. Scaling, management,
Application Tier
security, and reliability can be handled differently at each tier.

​Tiered architectures must be carefully built to maintain performance since each

layers adds latency because of increased network and overhead delays.
Data Tier
​Within a given tier, processes might be distributed across machines or across
different data centers. The usual way of scaling within a tier involves some form
of horizontal scaling.

​CS462 – Large-Scale Distributed Systems 26

Lesson 02: Distributed System Patterns

Horizontal Scaling

​Horizontal scaling is applicable where

processes are parametrically similar.
​For example, Web servers can be scaled by
making copies of the Web server and routing
requests via a load balancer to anyone of N
servers. Scaling involves adding more
servers of the same type.
​Horizontal scaling sometimes involves routing requests
with specific properties to a specific server. For example,
Web server frequently do session pinning where a
specific user, identified by session ID, is sent to the same
server on subsequent requests.

​Similarly, sharding sends data requests to a specific data

base server based on specific properties of the data
request.

​CS462 – Large-Scale Distributed Systems 27

Lesson 02: Distributed System Patterns

Peer to Peer

​The nodes in a peer-to-peer (P2P) system are not

distinguished from each other in capability or
interconnectedness.
​That doesn’t imply they might not play different roles or run
different algorithms.
​The Internet (not the Web) is the largest single example of a P2P
system. Any node on the Internet can communicate with any other
node.
​Building P2P systems without any central coordinator is a
challenging task and will comprise a significant portion of this
class.
​

​CS462 – Large-Scale Distributed Systems 28

Conclusion ​Summary & Review
​Credits
Lesson 02: Distributed System Patterns
Summary and Review
This lesson has looked at several important
concepts that will guide us in our explorations.
Coupling is at the heart of what makes
distributed systems hard to build and tricky to
operate. No useful system can avoid it, but we
can reduce it.
There are multiple design axes that affect the
behavior, performance, scalability, and cost of a
distributed system. We will use these as we
design distributed systems.
​CS462 – Large-Scale Distributed Systems
​The word distributed is used as a catchall for
systems that are decentralized, heterarchical, or
merely distributed. Yet these terms mean very
different things. We can design systems that
have any or all of these properties.
​In doing so there are numerous interconnection
patterns we can choose from. This choice has
significant impact on the operation of our
system. Consequently, we’ll review each of the
architectural patterns (except for the multi-tier
model) in detail in coming lessons.
30
Lesson 02: Distributed System Patterns

Credits

​Photos and Diagrams:

Ø Tied Shoelaces (https://www.flickr.com/photos/sobriquet/314024495), CC BY-NC-SA 2.0
Ø Computer Scrap (https://www.flickr.com/photos/investingingold/7361094822), CC BY 2.0
Ø Fully-Connected Topology (https://commons.wikimedia.org/wiki/File:NetworkTopology-
FullyConnected.png), Public Domain
Ø 3D Tin Can Phones (https://www.flickr.com/photos/86530412@N02/8210762750/), CC BY 2.0
Ø Stack of HDD’s (https://www.flickr.com/photos/ervins_strauhmanis/9961198294), CC BY 2.0
Ø Centralized, decentralized, distributed (https://en.wikipedia.org/wiki/File:Centralised-
decentralised-distributed.png), CC BY-SA 3.0
Ø iOS 8 Icons (https://www.flickr.com/photos/microsiervos/15398845851), CC BY 2.0
Ø Chord network (https://commons.wikimedia.org/wiki/File:Chord_network.png), CC BY-SA 3.0

​CS462 – Large-Scale Distributed Systems 31