Architecture Patterns for Building Distributed Systems

UPI Study › Courses › Software Engineering › Free lessons › Lesson 15.3 Free with a free account

Architecture Patterns for Building Distributed Systems

Software Engineering · Chapter 15: Distributed Systems, Services, and Sociotechnical TopicsSection 15.3 · lesson 97 of 1037 min · free with a free account

← Client-Server Networks: How They Work and When to Use ThemNext lesson: Service-Oriented Architecture and SaaS →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

Peer-to-peer, broker, and distributed objects - when there's no natural center.

  • Explain why client-server isn't the only distributed shape
  • Describe peer-to-peer, and the problems it suits
  • Describe the broker and distributed objects patterns
  • Compare the patterns, and pick the one a problem's shape suggests

Transcript

Everything said in the video, section by section (902 words). Read along, or search it.

Distributed Systems, Services, and Sociotechnical Topics

Architecture Patterns for Building Distributed Systems

Client-server assumes one or more central servers, providing a service to many dependent clients. But not every distributed problem has a natural center. This section surveys three patterns for the shapes client-server does not fit.

Beyond Client-Server

Not Every Problem Has a Center

Client-server organizes a system around a clear distinction between a service provider, and the clients that depend on it. That is a useful default. But it is an assumption, not a law. A file-sharing network among equal participants does not fit it. Neither does a marketplace of buyers and sellers who never interact directly. And neither does a system of objects scattered across machines, which still need to interact as though they were local. Three patterns emerged for these shapes. Peer-to-peer, broker, and distributed objects.

Peer-to-Peer

No Fixed Center

Client-server routes everything through one center. Peer-to-peer removes the fixed center entirely. Its participants, called peers, act as both consumers and providers of a service, with no single central authority doing the heavy lifting. Any peer can request something from, or offer something to, any other peer directly. It suits file-sharing networks, some distributed-ledger systems, and collaborative applications with no single owner.

Table 1

Peer-to-Peer Trade-offs

Peer-to-peer brings real strengths. Resilience, because no single peer's failure stops the system. And scalability, because each new peer adds resources, as well as demand. It also brings real costs. With no central authority, coordinating behavior and guaranteeing consistency become harder. And establishing trust between strangers is harder too.

Broker

A Go-Between

In a broker architecture, a broker component sits between service providers and service requesters. Providers register what they offer with the broker. Requesters ask the broker for a service, rather than asking any specific provider. And the broker finds a match, and coordinates the exchange. It suits message-queue systems, service marketplaces, and middleware connecting many independent applications.

Figure 3

Neither Side Knows the Other

Here is the broker in action. Providers register with the broker. Requesters ask the broker for a service. The broker matches each request to a suitable provider. Neither side ever needs the other's identity. The broker is what connects them.

Table 2

Broker Trade-offs

That arrangement decouples each side from the other. A provider can be added, removed, or replaced without any requester needing to know, and the same goes the other way. So new participants join easily. The cost is that the broker itself becomes a critical component that everything depends on. If it is not built to handle that responsibility, it becomes a bottleneck, or a single point of failure.

Distributed Objects

Making the Remote Feel Local

In a distributed objects architecture, objects that may be running on different machines interact through method calls that look like ordinary object-oriented calls. The calling object does not need to know whether the object it calls is local or remote. The infrastructure locates it, and carries the call across the network. The call in the code looks identical either way. But the network hop underneath is very real.

Table 3

Distributed Objects Trade-offs

That transparency has a clear strength. Developers can reuse familiar object-oriented thinking, and existing object designs, across machines. But it also has a real cost. A remote call is far slower, and far less reliable, than a local one. And code written as though the difference does not matter tends to handle network delay and failure poorly. This pattern suits enterprise systems of many independently deployed components, that still need to act as one coherent object model.

Table 4

Which Shape Does the Problem Have?

None of these patterns, or client-server itself, is correct in general. The question is which shape the problem already has. Is there a natural, stable provider? That suggests client-server. Is there no natural center, or does resilience matter most? That suggests peer-to-peer. Does either side need to change without the other knowing? That suggests a broker. And do many independent pieces need to feel like one object model? That suggests distributed objects. Real systems can combine them. A peer-to-peer network might use a small broker, just to help new peers find each other.

Apply It

2 Systems to Diagnose

Let's apply that to two systems. Thousands of home sensors share readings directly with each other, with no company-run server at any point. Each sensor is both provider and consumer, with no center. That is peer-to-peer. Now a team builds a distributed objects system, treating every remote call exactly like a local one, with no handling for delay or failure. It works fine in testing on one machine, but breaks constantly once deployed across a real network. Testing on one machine never exercised a real network hop. The pattern's convenience was mistaken for a guarantee it never made.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Peer-to-peer is an architecture where participants, called peers, act as both client and server to one another, with no fixed center. A broker is a component that matches service providers to requesters, so neither side needs to know the other directly. Distributed objects is an architecture where objects on different machines interact through method calls that resemble local ones. And a remote method call is a call to an object on a different machine, made to look like an ordinary local call.

Key Takeaways

What to Carry Forward

To pull this together. Client-server assumes a natural center, and not every distributed problem has one. Peer-to-peer removes the center, trading easy coordination and trust for resilience and scalability. A broker keeps providers and requesters decoupled, but becomes a critical, potentially bottlenecked component itself. Distributed objects make remote calls look local, which can hide the real cost of a network hop. And the right pattern is the one that matches the shape of the problem. Real systems often combine more than one.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Architecture Patterns for Building Distributed Systems

What is peer-to-peer architecture and when is it used?
Peer-to-peer is an architecture in which participants, called peers, act as both consumers and providers of a service, with no fixed central authority. Any peer can request from or offer to any other peer directly. It suits file-sharing networks, some distributed-ledger systems, and collaborative applications with no single owner, such as home sensors sharing readings without a company-run server.
What are the trade-offs of peer-to-peer versus client-server?
Peer-to-peer gains resilience, because no single peer's failure stops the system, and scalability, because each new peer adds resources as well as demand. In exchange, coordinating behavior, guaranteeing consistency, and establishing trust between strangers all become harder without a central authority. Client-server keeps that central control but depends on the server as a center.
How does the broker architecture pattern work?
In the broker pattern, service providers register what they offer with a broker, requesters ask the broker for a service, and the broker matches each request to a suitable provider and coordinates the exchange. Neither side needs the other's identity, so providers and requesters can be added or replaced independently. The cost is that the broker can become a bottleneck or single point of failure.
Why can a distributed objects architecture fail once deployed on a real network?
Distributed objects make remote method calls look identical to local ones, but a remote call is far slower and less reliable. Code written as if the difference does not matter tends to handle network delay and failure poorly. A system tested on one machine may work fine, then break constantly when deployed, because testing never exercised a real network hop.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →