Architectural Patterns: Catalogs, Styles, and Case Studies

10.1 Three Ways to Catalog Patterns

10.1.1 Module, Component-and-Connector, and Allocation Families

There is more than one catalog of architectural patterns. An earlier session covered a catalog of distributed patterns — patterns for systems whose pieces run on different machines. This session organizes the same body of knowledge in a different way, by splitting every pattern into one of three families. Think of the families as three questions an architect is allowed to ask about any system:

1. Module patterns — patterns that shape how code is divided into units. The layered pattern is the classic example here: you take a topic, divide it into parts called layers, and each layer uses the next layer below it. The question this family answers is "how do I split my code?"
2. Component-and-connector patterns — patterns about interaction. You have blocks or subsystems that interact with one another, and the nature of the interaction differs from pattern to pattern. Broker, model-view-controller, pipes and filters, client-server, peer-to-peer, publisher-subscriber, shared data, and service-oriented architecture all live in this family. The question this family answers is "how should my pieces talk?"
3. Allocation patterns — patterns about mapping software to the world it runs on. Multi-tier and MapReduce belong here; they talk about how software modules map onto hardware modules. The question this family answers is "where should my software sit?"

A useful way to remember the split: module patterns are about the shape of the code, component-and-connector patterns are about the conversation between pieces, and allocation patterns are about the address of each piece on real hardware. Reference books such as Gomaa's catalog group their patterns similarly — structure patterns, communication patterns, transaction patterns — which is the same instinct applied with different labels.

The same pattern can be viewed through more than one lens — layered is listed under module, yet a layered system deployed across machines starts to look multi-tier — but knowing which family a pattern belongs to tells you what kind of question it answers before you read a single detail page. That is exactly why catalogs exist: they trade a little memorization for a large amount of orientation.

10.1.2 Recognizing Patterns and Their Benefits

A working architect needs the ability to "smell" these patterns when looking at an existing architecture. Nobody hands you a diagram with the patterns labeled; you see boxes and arrows, and the skill is to recognize which named pattern the structure is an instance of. These are the major patterns, and each has many variations. Think of the standard form as the vanilla pattern — the plain, textbook version; everything else is a variation of it, the way every ice-cream flavor is a variation of the plain scoop.

The practical skill works like this: you see a structure, you name its pattern, and the moment you have named it, you can state the benefits of using it. Naming is the key that unlocks the rest, because every pattern exists because it buys specific benefits — layered buys separation of concerns, broker buys location transparency, pipes and filters buy interchangeability. If you know briefly what each pattern is, you can always read the details later and understand what benefit the pattern was bought for. Without the name, the same details are just noise.

Real-world: this recognition skill is exactly what you use when you join a team and must read an unfamiliar system quickly — spot the pattern first, then the details fall into place. It is also how experienced architects review proposals: they are not reading every line, they are asking "which pattern is this, and did the designers pay attention to the costs that come with it?"

10.2 A Guided Tour of Component-and-Connector Patterns

This tour walks through the component-and-connector family quickly, one stop per pattern. The rule of the tour is the recognition skill from section 10.1: at every stop, learn the vanilla form of the pattern — its standard shape — and attach one benefit and one cost to it. Many variations of each pattern exist in practice; if you know briefly what each vanilla pattern is, you can always read the details later and understand what benefit it was bought for. Deeper treatments come later in this lecture (layered in 10.7, broker and proxy in 10.8, pipes and filters in 10.9, MVC in 10.11, SOA in 10.12).

10.2.1 Layered, Broker, and Model-View-Controller at a Glance

The layered pattern divides a system into parts where one layer uses the next layer down — presentation uses business, business uses data access. It is covered in depth in section 10.7.

A broker is an in-between component placed among two blocks. It helps a collection of blocks interact through one common point: services register with the broker, clients send requests to the broker, and the broker forwards or directs each request to the right service. Clients never need to know where a service actually lives — that property is called location transparency, and it is the main thing the broker is bought for. The price is that the common point can become a bottleneck under heavy load, and if it dies, everything behind it becomes unreachable. Sometimes you keep a backup for it despite the bottleneck, because funneling everything through one point buys you three things: no duplication of work (one place does the job instead of many), maintained consistency (everyone sees the same state), and proper allocation of resources (the broker can ration who gets served when). A broker serves many purposes at once.

Model-view-controller (MVC) keeps one model, which maintains the data store, and offers many possible ways to look at that data. Views can be visualizations, graphics, tables, or simple lists — same numbers, different faces. A controller manages user interaction: the user interface connects to the controller, and the controller plays the role of an umpire who decides what needs to go to the model and what the views are allowed to see. Section 10.11 develops MVC fully.

10.2.2 Pipes and Filters, Client-Server, and Peer-to-Peer at a Glance

Pipes and filters looks like the piping network in a house or a factory. Blocks are connected by pipes. Each block is either a reservoir (it holds data) or a process unit (it transforms data). The pipes carry a common flow pattern. There can be slight variations between pipes, but if the pipes are absolutely uniform, then the modules between them become interchangeable — you can unplug one unit and plug in another freely, because every joint fits every unit. When you design a system so it can be rearranged like this, you have built a pipes-and-filters architecture. Section 10.9 goes deeper.

The client-server pattern applies when you decide that one powerful machine should provide a particular class of service. The client makes requests; the server answers them and never initiates them. The machine is capable of serving a very large number of users without being overburdened. Why put everything there? Reuse (every client shares the one implementation), common control (rules change in one place), and the freedom to give that machine very specialized features tuned to that one type of service. Typical examples are database servers and mail servers — the big ones.

Real-world: conventionally even storage sat on servers. Storage servers let people just save files centrally. Even today some companies — not IT companies, say a design firm — keep one local server, give engineers access to it, and tell them not to store anything anywhere else. A more useful way to work would be a shared file service such as Dropbox, OneDrive, or Google Drive, yet local servers still sit in offices, switched off at night, making their owners feel secure. The server is doing its job; the habit around it is what aged.

Peer-to-peer is everybody talking to everybody. Its advantage: there is no single common point whose failure kills the system — every node is a full participant, both asking and answering. WhatsApp feels like this, though in truth it does have central points that coordinate message delivery. Torrents are genuinely peer-to-peer: content opens out on the World Wide Web, gets distributed everywhere in pieces, and is collated back together from the pieces by whoever wants it. Reference texts treat peer-to-peer as a variation born from client-server where the client and server swap roles — every machine plays both.

10.2.3 Service-Oriented Architecture at a Glance

Service-oriented architecture (SOA) has been extremely popular over the last ten to twenty years and has been the subject of seminars for two decades. Many careers have been built on it. Its rise happened largely because legacy applications coexist with modern systems: a very large segment of SOA work consists of integrating legacy applications with current-day technologies, without rewriting the legacy side.

The move is this: you build a shell around an application. That shell becomes a service. The service offers functions to new applications through an agreed interface. Behind the service sits whatever application you like — the outside world does not care what is underneath, and the underneath can be replaced without anyone noticing as long as the shell's contract holds. People developing user interfaces or other applications interact only with the service, and the service interacts with whatever lives at the back. That arrangement is service-oriented architecture. Section 10.12 develops it fully.

10.3 The Publisher-Subscriber Pattern

10.3.1 Request-Response versus Subscription

The publisher-subscriber pattern underlies even the model-view-controller arrangement described later in section 10.11, so keep it handy. In publisher-subscriber, there are people who require a service, but the service is not handed out on request. You cannot simply arrive with a user ID and password and pull the data. That model does not suit the situation, because you want to access the service not by requesting it but by being informed by it: "I've got something new to offer you. Take a look."

The cast has two roles. The publisher is the side that produces updates and keeps a subscriber list: an enrollment of everyone who said, in advance, "tell me when this kind of thing happens." The subscriber is any party that registered itself on that list. Registration usually names a type of message ("ticket available", "temperature crossed the limit") rather than one specific event, which is what makes the arrangement selective — subscribers hear about their kind of news only.

Compare the two styles directly:

• In client-server, you tell the server "I want a ticket," then stand in a queue. As and when your turn comes, the ticket is issued and you go back. You may work synchronously or asynchronously — either way, you asked first.
• In publisher-subscriber, there is a message that is supposed to reach you. The publishing side comes to know that something new exists — say a ticket is available. It looks up its list of subscribers for that particular service: "these are the subscribers, let me intimate them." It sends a message. Very often, receiving that message triggers a procedure at the subscriber's end which automatically fires a request back to pick up the update.

So the moment a subscriber hears from a publisher that there is an update, the request to fetch that update is triggered automatically, without a human asking. The notification works as a doorbell, not as a delivery: it tells you to come, it does not hand you the parcel.

Visualize it as a switchboard with a pegboard: each subscriber holds one peg (a registration) on the publisher's board. When news of a given type arrives, the publisher rings every peg of that type — nothing more. Add or remove a peg and nothing else about the system changes, which is why this pattern scales to many kinds of listeners without redesigning the publisher.

10.3.2 Why Notification Instead of a Data Push

A natural question follows: if the publisher already knows there is an update, why trigger a request? Why not send the data straight away?

The reason is control. Let the subscriber decide what is to be picked up, in what form, and in what detail. Everything is decided by the subscriber. The subscriber does not have to receive a huge bundle of data it does not want. Depending on the type of subscriber, the purpose of use, and the detail of use, each subscriber can be coded differently to pick up a different type of detail from the same notification. One listener fetches just the headline number, another pulls the full report, a third ignores the content entirely and merely logs the timestamp — all from one identical notification.

Real-world: this is exactly how phone notifications behave. You subscribe to notifications on your mobile phone; they keep arriving whether or not you act on them. Some apps react automatically — a notification arrives and the app triggers, shows a display, rings an alarm, or sends another message on its own. Acting on the notification is the receiver's choice, not the sender's.

Real-world and domain connection: stock tickers, flight-status alerts, and factory alarm systems all run on this pattern — the event source publishes once, and dashboards, phones, and loggers each pull their own slice. In enterprise software the same shape appears as messaging systems where applications subscribe to message types rather than call each other directly.

10.4 The Shared-Data Pattern

10.4.1 One Repository, Many Users

The shared-data pattern is the simplest idea in the connector family: put a lot of data in one place and let many people use it. The central store is called the repository — the single named home of the data. The repository could live in file systems, object storage, a relational database (RDBMS), or NoSQL stores — any sort of data counts. The store may sit in one place or be distributed, and a number of users draw from it.

The roles are minimal: many producers write into the repository, many consumers read from it, and neither side talks to the other directly — all contact happens through the data itself. That is also the deep difference from publisher-subscriber: there the news travels to you; here you visit the news. Nobody notifies anybody. If a consumer wants to know whether anything changed, it looks.

When the design problem is mostly "many consumers need common data," and the interesting structure is the data itself rather than the messages around it, the shared-data pattern is the answer. Designing something purely for data availability is a legitimate architecture in its own right.

Real-world and domain connection: data warehouses and analytics platforms are industrial-strength shared-data systems — dozens of source systems load figures into one store, and reporting teams across finance, marketing, and operations all draw from it without ever contacting the source systems.

10.5 Allocation Patterns: Multi-Tier and MapReduce

10.5.1 Multi-Tier versus Layered

Allocation patterns describe where software sits on hardware. The multi-tier pattern is different from the layered pattern, and the difference matters. Multi-tier talks a lot about mapping software modules onto hardware modules — a tier is the hardware side of the bargain: one server, or one group of servers, that hosts some of the software. A layered pattern enforces a one-way flow of traffic between layers: each layer uses only the layer below. Multi-tier allows different forms of storage and different traffic paths between tiers — a tier may host several layers at once, and traffic can flow in patterns that suit deployment rather than a strict stack.

The clean way to hold the distinction: layers are logical, tiers are physical. Layers divide responsibility inside the design; tiers divide location across machines. Three layers can live happily on one machine (one tier), and the same three layers can be spread across three machines (three tiers) without changing a line of logic — only the deployment changes. Reference texts say exactly this: layers take no account of physical location; tiers are all about it. If the distinction is not clear to you, take some trouble and look it up on the internet — the vocabulary of tiers versus layers trips many people, and mixing the two words in an exam answer is a classic slip.

10.5.2 MapReduce: Send the Software to the Data

The most important allocation pattern in the current context is MapReduce. With the arrival of distributed computing and large database applications, the volumes involved stopped being describable in tons — and "tons" is an understatement. We normally jump from kilobytes to calling them kilos, and a thousand kilos make a ton; here we are talking about petabytes of information that need processing. A petabyte is a million gigabytes — no single machine moves that through one program's queue in useful time.

Now consider what happens if all that data must sit in a queue waiting to be processed by one particular piece of software. It will never happen. The world would wait perpetually for results. Moving the data to the software also means dragging petabytes across networks whose capacity is tiny compared with the data itself.

The inversion that fixes this: instead of getting the data to the software, send the software to the data. Wherever data lives, ship the program there and let it process the data in parallel. A large number of machines all over the world can execute a common process on data lying locally on each machine. Once each machine has processed its local share, the results are merged — reduced — and made available to whoever requires them. You mapped the program onto the data, then reduced the outputs into one result — map, then reduce. That is where the name comes from.

The procedure has a fixed shape:

1. Split the dataset across many machines (usually it already lives distributed).
2. Map: every machine runs the same small program over its local share, emitting partial results.
3. Shuffle/group: partial results are collected by key so like items travel together.
4. Reduce: grouped items are merged into final answers.
5. Serve the merged result to whoever requires it.

The cost profile follows directly: the map phase scales almost perfectly because machines never talk to each other; the reduce phase concentrates traffic, so it is where systems feel strain. Open-source frameworks such as Hadoop industrialized exactly this recipe for clusters outside Google.

10.5.3 Google's Early Use at Planetary Scale

An early large-scale user of this style was Google. When you start typing a search, an enormous mechanism running across the world processes the stream of queries arriving at every instant — no single computer could stand in that river. Take the time to look up the range of services Google offers and you will be shocked: there are over a hundred completely different types of services, and a good number of them are AI services.

Google also stumbled publicly along the way: it released Bard, became the subject of jokes across the internet after some wrong answers, and later renamed the product Gemini. The renaming was not only image repair — the technology inside Gemini is apparently more advanced, and the newer releases are strong products. Google had been using what we now call artificial intelligence for a very long time before the terminology caught up; appropriate labels for these applications took years to appear.

Real-world and domain connection: beyond search, the same pattern powers log analysis at banks, clickstream analytics at retailers, and genomic batch processing in bioinformatics — anywhere the data outgrew one machine and someone chose to move the code instead of the bytes.

10.6 Using AI Assistants as Study Tools

10.6.1 Stateful Chats versus Stateless Searches

There are lovely AI products available now. Bots operate on Twitter and Facebook, collating information and responding with AI capabilities. For study, tools such as Gemini, ChatGPT, and the many derivative products that embed these models as a back-end service are genuinely useful. Some of them allow only five interactions per day or another limited number — use that allowance rather than letting it expire idle.

Say you want to study the broker pattern. Open a chat on that topic. Ask questions, receive material, ask further questions, dig deeper. This works for examination preparation too. The key property that makes this powerful: conventional web searches were stateless — every search stood alone, remembered nothing about your previous search, and had nothing to do with it. Each query was a stranger walking in off the street. A chat is stateful: it generates a session, remembers your previous interactions, and responds in light of them. You never repeat yourself. That memory makes conversing with an AI tool a very effective way to discuss a subject — the conversation accumulates, like office hours with a patient tutor who never forgets what confused you ten minutes ago.

10.6.2 Practical Uses and Ownership Warnings

Concrete ways to use these tools well:

• Making a presentation, writing an essay, or writing a letter when letter-writing is not your strength? Submit the draft and ask for improvements.
• Preparing a subject? Give the tool the syllabus and ask it to summarize the syllabus for you, then ask for references.
• Want to see many component-and-connector diagrams? Ask: "please give me a few URLs where I can see component-and-connector diagrams for software architecture." It will return references, so you can focus on your area of concern.

Taken to an extreme, the tool could even do your assignment for you. Even if you go that far, take ownership of what the bot produces for you. Otherwise it becomes the emperor's new clothes: the output can make a laughing stock of you — everyone around you sees there is nothing there except you. Unintended comments land people in language that makes them look outright foolish — a large company's public AI stumble showed exactly this. Make sure nothing you submit looks like an obvious copy-paste, like ready-made material lifted from a wiki or a textbook. Chatbots even apologize when corrected — "yes, I misunderstood, sorry for misleading you" — which shows how confidently they can be wrong. An apology is not a correction of record; it is proof the earlier answer was invented. So understand every word of anything you copy from them.

10.6.3 The Technology Misuse Debate

AI misuse will become a big subject, just as it has for every technology. The classical answer applies to any form of technology — it applied to fire, it applied to the bomb: it is the misuse of technology that is dangerous, not the technology itself. Whenever we hold technology, we must hold it in mature hands. History's gravest example: the order that led to Hiroshima, with over 70,000 people dead in the second bombing and countless others injured for life — a price of technology almost too heavy to judge — and yet today we depend on nuclear energy as one of the cleaner sources of power. The same invention sits at both ends of the scale; the difference is the hand that holds it.

People argue that AI is used for cheating and that students stop applying their own brains. But apply the same logic to lighting a fire: why use a matchbox or a lighter? Why not sit down knocking stones together — because you fear spoiling your habit? When a form of technology exists, the goal is to use it appropriately. A teacher guides you through a class to give you an overall perspective so you can build knowledge; an AI tool, used well, extends the same idea: read as much as you can, understand as much as you can, then rely on your own intelligence to apply the knowledge when you face the question paper.

10.7 The Layered Pattern in Depth

10.7.1 Context, Problem, and Solution

Recall that a pattern is described as context, problem, and solution. For the layered pattern:

• Context: you want to evolve each module separately and independently; you want large developer teams; you want concerns separated totally — so much so that different companies can work on different layers.
• Problem: how do you divide a system so that teams never step on each other and pieces can be swapped without breaking the whole?
• Solution: stack the system into layers where each layer uses only services of the layer directly below it, and communicates through defined protocols.

The benefits follow from that separation. You can plug a layer supplied by one company together with a layer supplied by a different company. When an upgrade comes, you upgrade a single layer, and as long as it maintains the communication protocol with the layers above and below it, everything keeps working. Modifiability improves. Reuse improves. Complication drops, because not everything interacts with everything else: keep the top and the bottom interfaces common, and change anything in between freely. Once a layer's communication protocols are defined, the layer becomes a standard product that an architect in a completely unrelated environment might pick up and plug in. Reference catalogs record exactly these strengths — layers promote extension and contraction of the design — along with the matching weakness we will meet in 10.7.4: traversing many layers costs efficiency.

The construction recipe: create modules; separate the functionalities so each module holds one concern; enforce a unidirectional flow; define each block as a separate unit with its interaction protocol; then develop each module on its own. Notice the order — the protocol boundary is designed before the internals are built, which is what lets two companies build two halves independently.

Visualize the stack as a wedge of floors in a building with one staircase: floor n can send requests down to floor n−1 through the stairwell, and results come back up the same stairwell. No window between non-adjacent floors exists — and that absence is a feature, because it makes every dependency visible and countable.

10.7.2 The One-Layer Constraint and Variations

Here is the strict constraint of the layered pattern: a piece of software can belong to only one layer. Code written inside one layer cannot be used by another layer. If you want the same module in a second layer, you make a separate copy and hand it over there. And the beauty of the copy: the people working in the other layer are free to modify it however they like. It is their component now — they are not sharing anything with you. Sharing would create a hidden coupling across the boundary; copying keeps each layer self-contained, which is precisely what the pattern is buying.

Things are not always cut and dried, though. Variations exist. If some major component is needed by two layers, it can be provided as a service outside the application, and each layer uses that service. Texts also describe relaxed forms where a layer may skip past its immediate neighbor under controlled rules. There are no vanilla solutions in practice — whenever you apply a model, you adapt it.

10.7.3 Models Are Simplifications: The Physics Analogy

Why do simplified models still help? Physics class offers the perfect picture. You apply a formula the way it was taught:

$$v=u+at$$

where $v$ is the final velocity of the object, $u$ is its initial velocity, $a$ is its constant acceleration, and $t$ is the time elapsed. You compute how far a ball will travel and where it will fall. Then you reach college, take physics again, and are told: you forgot the air — the resistance offered by the air. All of school physics assumed a vacuum.

The formula itself is worth one line of trust-building, since every symbol must earn its place. Check the units: $u$ and $v$ are velocities (meters per second), while $a$ is acceleration (meters per second per second), so multiplying by time $t$ gives meters per second again — all three terms share units, so adding them is legal. Check the limiting case: if there is no acceleration ($a=0$), the equation says $v=u$ — the object keeps its initial velocity forever, exactly Newton's first law. (Notation note: some books write the same equation as $v=v_0+at$; the lecture uses $u$ for the starting velocity.)

We build models in vacuums. We build them to gain a vocabulary and a basis for thinking about what happens. It is not necessary that reality matches the model exactly — and that is fine. The same holds for architectural patterns: the vanilla form gives you the vocabulary; the real system always adds friction the model left out.

10.7.4 The Cost of Layering

Layering is not free. Earlier separation adds cost, and you must stay constrained by it. Picture a company: top management, middle management, supervisors, workers. If a worker wants something sanctioned by the board of directors, the request must pass through every stage. Call it a weakness: decisions take a long time, and sometimes information does not even cross sideways. So be it — without that structure the organization would not function at all. You accept the costs of the form. Layered software carries the same performance penalty — every request pays a traversal tax through each intervening layer — and you cannot wish it away.

10.7.5 Why Classic Patterns Still Matter

Someone asks: in a generation of microservices, tablets, and cloud computing, why discuss these old applications at all? The reality is that all these older technologies and techniques exist today, and even the most advanced services use these patterns in their building blocks.

Two analogies nail it. However complex the music, you still need your do, re, mi, fa, so, la, ti, do — or sa, re, ga, ma, pa, dha, ni, sa. With the most complex English constructions, you still need your ABC and your grammar constructs. People mangle English with slang and variations, but even to slang it well you must know the language. With patterns: learn the classic patterns to understand whatever patterns — or non-patterns — you work with today.

Real-world and domain connection: operating systems, network protocol stacks, and software product lines are the canonical layered deployments — kernel below, drivers above, applications on top — and every major cloud platform still ships its services arranged in exactly such stacks.

10.8 The Broker Pattern and Its Proxy

10.8.1 What a Proxy Does

Broker solutions often come packaged with the concept of a proxy — a stand-in component that sits on the client's side and acts on the client's behalf. The everyday sense helps first: in school, "proxy attendance" meant someone marked attendance for an absent friend. The legal version: company shareholders who cannot attend a meeting appoint a proxy to vote for them. With online voting, people collect proxies so they arrive holding, say, proxies from 51% of the shareholders — and can tell the room, "you better sit and listen to me." In every version, one party carries another's authority so the principal does not have to show up.

In the broker pattern, a proxy makes communication easy in front of the broker. You do not have to go beyond the proxy for information that does not relate to the broker's core job. Three jobs fill that description:

• Cache: the proxy remembers answers close to the requester. Once it has fetched something, repeat requests are served locally — faster, and without loading the broker.
• Converter: it can convert data intermittently into a form the broker can use as it likes — translating formats at the edge so neither end has to speak the other's dialect.
• Local agent: it renders lots of local services on the client's behalf — queuing, buffering, small housekeeping — so the client deals only with its neighbor.

Visualize the arrangement as a shop counter at the end of your street: most needs are met right there from stock on hand (the cache), odd-sized orders get repackaged before being sent onward (the converter), and parcels you hand over are held until the delivery truck comes (the local agent). Only genuinely central business travels all the way to the broker.

10.8.2 Mail Proxies and Web Proxies

Mail proxies show the idea at its most useful. Local mail gets distributed directly by the proxy without ever reaching the mail server. When the internet connection is down, the mail proxy holds all outgoing mail; the moment the server becomes reachable, the proxy pushes everything through. Clients do not have to stay logged in: a client simply hands its mail to the mail proxy and logs out. This was one of the major early uses of a proxy server.

Web proxies are the other common case: access to the internet itself may route over a proxy — pages fetched once for one user are cached and served to the next user who asks for the same page, which is why organizations run them both for speed and for controlled access. Various broker solutions exist beyond these; going through them at leisure rounds out the picture.

Real-world and domain connection: content delivery networks run the same play at planetary scale — edge servers cache and convert close to users so the central origin (the broker of content) handles only what truly needs central attention.

10.9 Pipes and Filters in Depth

10.9.1 Streams, Transformations, and Compatibility

The context of pipes and filters: a stream of data moves from module to module, the output of one becoming the input of the next, and inside each module a single transformation takes place. Unix commands are the canonical example. Each command handles one particular activity: one sorts, one merges, grep filters out matching data, one reads data from the console, one compares two files. You chain them so things flow from one to the other along the common data pattern.

The engineering duty that makes it work: compatibility of data between one module's output and the next module's input. You design your blocks, and you design the structure of the data that moves through the pipes, so every joint fits. This is where the discipline lives — a pipeline is only as interchangeable as its data contract is uniform. The processing modules can fork out into parallel branches, fork in, and join again, so the shape need not stay a straight line. We call each processing module a filter — it does something to the data passing through.

Visualize an assembly line at a bottling plant: empty bottles enter a shared conveyor (the stream), each station performs exactly one operation — rinse, fill, cap, label — and because every station grips bottles the same way, stations can be inserted, removed, or reordered without stopping the line.

10.9.2 Worked Application Scenarios

Three application shapes show the pattern's range:

• Voice processing. Route the signal through filters, each performing one transformation on the stream — noise removal, then echo cancellation, then compression — none of which needs to know another exists.
• Forms and documents. A document moves from stage to stage, each stage performing one function — validation, extraction, formatting — until it emerges processed.
• Visa applications. Large numbers of applications arrive. Specialized modules process them in sequence, and those modules can carry local storage, holding data once taken in before releasing it toward the output and the next unit — a filter that buffers, useful when upstream stages produce faster than downstream ones consume.

You may also rearrange the order of the units, for several reasons. Maybe a bottleneck is forming somewhere. Maybe placing a particular stage earlier means a lot of data gets filtered out in advance, so the next stage carries a lower load. Load balancing and early filtering are the usual arguments for reordering the pipeline. In the visa flow, moving document-completeness checking to the very first stage means incomplete applications never occupy the expensive verification stages behind it — same filters, different order, materially different throughput.

Real-world and domain connection: media-encoding pipelines, ETL (extract-transform-load) jobs in data warehouses, and compiler passes — lexing, parsing, optimizing, code generation — are all industrial pipes-and-filters systems where each stage's output format is the next stage's contract.

10.10 Adapter versus Broker

10.10.1 Student Question and Full Answer

The translator story makes the difference vivid. A gentleman flies down from London to meet local political leaders who may not know English. They fix an appointment and meet in a five-star hotel. One rattles on in English, the other rattles on in Bengali, and neither understands the other. Is a broker required to resolve this? No. A broker would be needed if large numbers of people in England wanted to interact with large numbers of leaders here — scale on both sides is the broker's job. But even after fixing a broker, you might still need an adapter: somebody who listens to the Englishman and translates into Bengali, listens to the Bengali gentleman and translates into English. That person converts between two incompatible languages — that is the adapter.

When to pick which: if the pain is finding and coordinating many parties, broker; if the pain is two specific parties speaking incompatible formats, adapter — and large systems routinely use both at once.

10.10.2 Building an Adapter Between Two Systems

In software terms: sometimes established systems are available in the market, or components that are well-known and sturdy — but their interfaces do not match. Suppose everything system A requires can be deciphered from the output of B, and everything B needs as input can be deciphered from the output of A. Then you write a component that takes the input coming from A, converts it, and feeds it to B in the format B expects. In reverse, when output arrives from B, the component takes it, performs the conversion, and provides it in the format A requires. That component is the adapter pattern. One converter, two directions, zero changes to either established system.

Real-world and domain connection: payment gateways that translate between a shop's checkout format and card-network protocols, and USB power adapters between wall sockets and devices, are everyday adapters; travel-booking platforms brokering between thousands of fliers and hundreds of airlines are everyday brokers.

10.11 Model-View-Controller in Depth

10.11.1 Motivating Scenario: The Automated Factory Floor

Walk through the factory scenario that motivates the pattern.

You run a factory. All the important data about the factory is available and updated from various sources. Transducers feed it in — a transducer is equipment that takes input in one form and converts it to another: temperature, pressure, humidity. Reports arrive. Certain systems push data: the sales system, the production system. Critical information, computed by certain processes, displays on large panels on the factory shop floor, totally automated — nobody decides what should show; the rules decide. Alarms trigger off in the factory when temperatures leave a safe range or fire is detected, and announcements go out. Departmental managers get summary reports, appearing automatically in their mailboxes, or on the console, or overriding whatever they were doing as an alert — the system handles interrupts that drive these displays. Some reports are available only on request. Notifications go to the mobiles of registered people, telling them updates are available. Some open screens viewing the data update automatically — the numbers change on screen while you watch, no clicking needed. Graphs render live. The CEO gets a summary report and probably keeps a wall screen showing major updates and yesterday-versus-today positions.

That is the context: one body of data, many audiences, many formats, many delivery channels. Sort the audience list and a pattern emerges:

Six different faces, one underlying set of facts. Building each face as its own little system with its own copy of the data would guarantee inconsistency; the fix is to separate what is known from how it is shown.

10.11.2 Roles and Interactions

Who wants to see what, and how they want to see it, is a user-interface problem. The user interface has a program that fetches data. To fetch it, the view informs the model: "I am interested in this class of data." The controller mediates between the model and the views. Instructions can flow from a view to the model — "give me this data." When users input data, the controller receives it and updates the model.

So the cast is: a distinct group of software modules called views — possibly a huge variety, with totally dissimilar natures of application — all accessing data from a common model, which is designed to provide the varying types of information required, and more. The controller takes instructions either from the views or from input devices, and updates the model accordingly. Any state change flows through the controller to the model; the view can make gestures and give options, which go to the controller; the controller updates the model; and the view can query the model when it needs current state.

10.11.3 Change Notification as Publisher-Subscriber

Here is the connection worth remembering: the change-notification side of MVC is the publisher-subscriber aspect. The model and the views interact as publisher and subscribers where notifications are concerned. All views register with the model — they tell it, "listen, I'm subscribing." If the parties are operated by different companies, there could even be a subscription fee; within one company, it is just a question of having the technology in place. The model notifies all subscribers when state changes.

It behaves like subscribing to notifications on your mobile phone: notifications keep arriving whether or not you act on them. Applications on the phone can also be triggered automatically by a notification — a display appears, an alarm rings, another message goes out. Whether and how to react is the receiver's decision. Likewise each view takes independent decisions about what to do with a change notification — the panel repaints, the graph appends, the mailer composes, all independently, from the same notification.

10.11.4 Independence, Security, and Diagram Conventions

Look at how departmentalized and simple the whole application has become. The model worries about its subscribers and notifying them, plus keeping certain ports available where it accepts queries. Those queries can arrive over a secure line; they can require user ID and password — meaning a state query may need identification, so the model authenticates the requester and only then responds. The model is a completely separate box. It could be developed by a separate company. The views simply use the benefits of the model.

The controller is the socially coupled member: its design normally has a lot to do with the view. The controller provides certain facilities, and if it was built with particular features, the view uses those features to inform the controller of whatever needs informing. Various solutions exist for wiring this trio; reading through them in detail pays off.

Real-world and domain connection: web frameworks popularized MVC for browser applications — routes act as controllers, templates as views, database-backed objects as models — and monitoring dashboards for power grids and trading floors are factory-floor scenarios in modern dress.

10.12 Service-Oriented Architecture in Depth

10.12.1 Providers, Consumers, and the Uber Example

Service-oriented architecture separates service providers, who offer services, from consumers, who need to consume them. The clean example: Uber consumes the service provided by Google Maps. Uber does not need to understand what Google is doing internally — whether they run one satellite, two satellites, or fourteen satellites is not Uber's problem. How data comes down from the satellites, what triangulation is performed, how readings from three satellites determine the latitude, longitude, and altitude of a point — none of that is Uber's concern. Uber knows only this: if I make a request to Google in the agreed format, Google provides the service. Provider and consumer are completely separate, and the consumer needs to know only what information to supply to get the response.

Reference texts state the same separation as design tenets: boundaries are explicit (crossing into a service costs a network hop, so it is designed deliberately), services are autonomous (each side deploys and evolves independently), the two sides share schemas and contracts rather than code, and compatibility is governed by published policy. Every one of those tenets is visible in the Uber–Google pair: the contract is the request format; the policy is authentication and usage terms; the internals on both sides can be rewritten overnight without the other noticing.

10.12.2 Services on Your Own Website and Commercial Models

The consumer side is open to anybody. Even for a personal website, you can configure access to services Google offers free of cost: write code in your web application that pulls data from Google Maps and overlays your own data on top of it. Write the directions to your office. Show the address of each of your offices worldwide, the contact person at each location, a guide to traveling to your office — one click on your website opens a page that guides a visitor there. Limited coding, free of cost, full interoperability benefit: Google developed the Maps application, and you offer its facilities as a service inside your own pages.

That is the pattern in one sentence: a service-oriented architecture distributes the facilities of an application to various people, so they may access it as a service. They do not buy the application from Google — they access it as a service. The commercial side flexes: the service could be free, chargeable monthly, charged per use, or billed on the quantum of data downloaded. Carry the concept forward and everything becomes available as a service eventually — infrastructure, platform, operating system: everything as a service. The essence is an architecture that offers any facility as a service to a large number of users, dissimilar users, for different purposes, across the internet.

Consumers can be other companies accessing over a browser, or email clients, or booking flows: a customer booking a hotel, airline, or bus ticket uses bank services to pay by credit card, and beyond the bank may touch authentication services from Visa or MasterCard. All those interactions are basically services talking to services — a single checkout quietly orchestrating half a dozen providers while the customer watches one screen.

10.12.3 Concrete Technologies and the Rise of APIs

Named examples ground this. Microsoft Communication Foundation and Microsoft Web Services: you write your services inside, they access your database, you write queries and call procedures inside the code, and you expose the result against a URL for users. That is a service-oriented architecture in practice — the URL is the contract's front door.

APIs have since become a subject in themselves — people specialize in API work — and at the base of API use sits a service-oriented architecture. Reference texts add the standards layer beneath such tooling: description languages that publish what a service offers, directories where services can be found, and message formats carried over ordinary web protocols. You do not need the acronym soup to grasp the shape: describe, discover, invoke — all through messages, never through shared code.

10.12.4 Facade versus Service-Oriented Architecture

Language precision matters here. When you describe something in its vanilla form, these terms apply cleanly and help mutual understanding. In a complex system, terms blur — it becomes a question of understanding each other. When you say facade and I say SOA, as long as we express ourselves to one another, it is perfectly in order.

10.12.5 Frameworks and Adapters in Practice

A shared-screen example tied the threads together: instead of accessing a logger directly, access an ILogger interface. Various logging implementations sit behind one common interface, and clients depend on the interface, not the concrete logger — an adapter-style move that decouples callers from implementations. Swap file logging for network logging and no caller changes a line, because the contract never moved.

Frameworks deserve their own definition. Development companies build patterns into frameworks. A framework is a large aggregation providing a controlled environment that can be used without having to reinvent the wheel — the structure, conventions, and plumbing come ready-made, and you fill in your part. Where a library waits for you to call it, a framework calls you: it owns the program flow and hands you the empty slots.

10.12.6 Open Platforms and Standardized Protocols

This style of integration has become a standard. Lots of platforms make their services available, so their communication protocols have had to be standardized. Travel is the visible case: MakeMyTrip, Yatra, EaseMyTrip, ClearMyTrip all interoperate with the same suppliers, which tells you the protocols are shared. The umbrella terminology is open platform communication. Every industry ends up with a protocol. Governments, too: the Government of India now receives a great deal of data using standardized protocols.

On the wire format: JSON is in popular use. Earlier, communication meant flat files with comma separators. Now that more people work in the object-oriented world, XML-based protocols appeared, and JSON is in major use. Banking shows how far standardization goes: enormous documentation exists, and banks' data-communication protocols are standardized — not only by RBI in India, but as international standards. Communicating over open platforms with common protocols has become fundamental to modern integration.

Real-world and domain connection: every major cloud platform is SOA industrialized — storage, messaging, payment, and mapping are consumed as metered services by millions of applications, exactly the free-to-paid spectrum and per-use billing described above.

Exam Guidance Summary

• Assignment guidance: identify patterns and bring out the discussion on patterns vividly and in full; cover everything that is asked for. Whatever else you do well, the pattern discussion is the flagged item.
• Sequence diagrams: describing one scenario as a sequence diagram is asked for, and it is not covered in class sessions. Go through the supplementary video session on drawing sequence diagrams (interaction diagrams). The goal is to express the dynamics of an application — an interaction scenario showing how the application pans out, message by message between components — not the quality scenarios studied elsewhere in the course. Most working students have met sequence diagrams already; if not, one focused self-study pass is enough.
• Question framing: exam questions are kept simple relative to the real world. Terms apply in their vanilla forms. Do not overcomplicate; recognize which pattern the question describes and state its benefits — the two-step reflex from section 10.1 is exactly what is being tested.
• Study approach: the subject is vast — almost impossible to pin to a syllabus. Read as much as you can, understand as much as you can, then apply your intelligence to the question paper. Marks follow from applying knowledge, not from memorizing boundaries.
• Self-study pointers: look up multi-tier versus layered on the internet if unclear; read through the various broker solutions at leisure; read the detailed MVC and SOA solution variants in the course material.
• Tooling advice: use limited-quota AI chat sessions deliberately for exam preparation — pick a topic, hold a stateful conversation, drill into confusion points.

Key Industry Applications

• Google — early MapReduce-scale user; search query processing distributed worldwide; over a hundred distinct services, many AI-based; Bard renamed Gemini after public missteps.
• Uber + Google Maps — the canonical service provider/consumer pair: Uber consumes mapping as a service without knowing satellite or triangulation internals.
• WhatsApp and torrents — peer-to-peer examples; torrents truly decentralized, WhatsApp nominally so.
• Dropbox, OneDrive, Google Drive — shared file services replacing local storage servers in non-IT companies.
• Twitter and Facebook bots — AI-driven information collation and response.
• Gemini and ChatGPT — stateful AI chat sessions used as study aids; derivative products embed them as back-end services.
• Unix command pipeline — sort, merge, grep, console readers, file comparers as filters joined by pipes.
• MakeMyTrip, Yatra, EaseMyTrip, ClearMyTrip — standardized open-platform communication in travel.
• Microsoft Communication Foundation and Microsoft Web Services — services written against databases and exposed at URLs.
• Visa and MasterCard — authentication services consumed during card payments inside booking flows.
• RBI and international banking standards — standardized bank data-communication protocols.
• JSON and XML — modern structured interchange formats replacing comma-separated flat files.
• TCP/IP protocol stack — the layered pattern's most famous instance, from application layer down to physical layer.
• ILogger-style logging interfaces — adapters decoupling clients from concrete implementations behind a common interface.

Each entry above is a named instance of a pattern from this lecture: when revising, walk the list once and recite which pattern each company or technology illustrates and what benefit that pattern was bought for.