Software Architectural Patterns

Chapters 3–5 taught you patterns for arranging classes inside one program. This chapter zooms out: how do you arrange whole components — servers, services, databases, message brokers — into a system that is fast, available, and changeable? You'll meet nine classic architectural patterns, trace requests through each one, and learn how to pick an architecture from a list of requirements.

From classes to systems: zooming out

A design pattern organises a handful of classes inside one process; an architectural pattern organises the whole system — often across many processes and machines. When you applied Strategy or Decorator, everything lived in a single running program: one address space, method calls that cost nanoseconds, no network in sight. Architecture is what you see when you zoom out far enough that individual classes blur into boxes labelled "web server", "business logic", "database" — and the lines between the boxes become network calls that can be slow, can fail, and can be intercepted.

What "architecture" actually means

A software architecture is usually described with three ingredients — worth memorising because every pattern in this chapter is just a different recipe using them:

Quality attributes: the forces that pick the architecture

Functional requirements ("the user can transfer money") tell you what code to write. On their own they often don't discriminate between candidate architectures — you could implement a funds transfer as a desktop app, a 3-tier web app, or fifty microservices. That's why, between otherwise-viable options, the force that usually picks the architecture is the quality attributes (also called non-functional requirements, or "the -ilities"):

Tiered architectures: 3-tier & MVC

3-Tier architecture architectural

Intent: split the system into three physically separate tiers — presentation, business logic, and data — where each tier talks only to its immediate neighbour.

The problem: the "fat client"

Before tiers, the common shape was 2-tier client–server: a desktop application (the "fat client") installed on every user's PC, talking straight to a shared database server. All the business rules live inside the desktop app:

// Runs on EVERY customer-service PC in the company
public void OnCheckoutClicked()
{
    // The database password ships to 500 desktops...
    using var conn = new SqlConnection(
        "Server=HQ-DB01;Database=Shop;User=app;Password=s3cret!");
    conn.Open();

    decimal total = LoadCartTotal(conn, _cartId);

    // Business rule buried in a button handler:
    if (total > 100m) total *= 0.95m;   // 5% discount

    var cmd = new SqlCommand(
        $"INSERT INTO Orders (CartId, Total) VALUES ({_cartId}, {total})",
        conn);
    cmd.ExecuteNonQuery();
    MessageBox.Show($"Order placed: {total:C}");
}

// TIER 1 — Presentation (browser / thin UI)
//   renders HTML, sends "POST /checkout" — contains NO rules.

// TIER 2 — Business logic (application server)
public class OrderService
{
    private readonly IOrderRepository _repo;
    public OrderService(IOrderRepository repo) => _repo = repo;

    public Receipt Checkout(int cartId)
    {
        var cart = _repo.LoadCart(cartId);
        decimal total = cart.Items.Sum(i => i.Price * i.Qty);
        if (total > 100m) total *= 0.95m;  // the rule lives HERE, once
        int orderId = _repo.SaveOrder(cartId, total);
        return new Receipt(orderId, total);
    }
}

// TIER 3 boundary — Data access
public interface IOrderRepository
{
    Cart LoadCart(int cartId);
    int SaveOrder(int cartId, decimal total);
}

The change request that kills the fat client: "the discount rule changes to 7% next Monday." Now you must rebuild and reinstall the app on 500 desktops — and until every machine is updated, different users apply different rules. Worse: every desktop holds database credentials (a security nightmare), and the database is doing all the shared work, so it becomes the bottleneck. The fix is to pull the rules out of the client into a middle tier that all clients share.

The structure

How a request flows

1. User acts — clicks "Checkout" in the browser. The presentation tier's only job is to turn that into a request: POST /checkout.
2. Business tier validates and decides — the application server authenticates the user, loads the cart, applies pricing and discount rules.
3. Business tier asks the data tier — it sends SQL (or an ORM call) to the database server; only the app server's credentials can reach the DB, which sits behind a second firewall.
4. Data tier answers — the database executes the transaction and returns rows.
5. Business tier shapes the result — computes the receipt, maybe caches, logs, audits.
6. Presentation renders — the browser receives the response and displays it. No rule was evaluated on the client.

You can watch this animated in the Request Tracer demo below.

Generalising: n-tier. Nothing stops you at three. Real systems often insert more physical tiers: a web tier (serves static content, terminates HTTPS) in front of an application tier, a caching tier (Redis) beside it, an integration tier talking to partner systems. Hence the generic name n-tier architecture. The constraint stays the same: requests flow through adjacent tiers, never skipping.

Benefits & drawbacks

Real-world examples: almost every web application you use — online banking, e-commerce, university portals. In the .NET world the canonical stack is: Blazor/React front-end (tier 1) → ASP.NET Core app on IIS/Kestrel (tier 2) → SQL Server (tier 3), and a typical solution mirrors it with MyApp.Web, MyApp.Services, MyApp.Data projects — layers that can be deployed as tiers.

Model–View–Controller (MVC) architectural

Intent: isolate business logic from the user interface by splitting into three roles — the Model (data + business logic), the View (what the user sees), and the Controller (interprets user input and coordinates the other two) — so views and logic can change with minimal impact on each other.

The problem: UI and logic welded together

The naive UI app puts everything in the event handler — the same disease as the fat client, but at class level:

public void OnFourButtonClicked()
{
    _runs += 4;                      // business logic...
    if (_runs >= _target)
        _resultLabel.Text = "WON!";  // ...fused to widgets
    _scoreLabel.Text = $"Score: {_runs}";
}

// MODEL — knows the rules, knows nothing about screens
public class Match
{
    public int Runs { get; private set; }
    public bool Won => Runs >= Target;
    public int Target { get; init; } = 120;
    public event Action? Changed;              // Observer!
    public void AddRuns(int r) { Runs += r; Changed?.Invoke(); }
}

The change request that kills the naive version: "we also need a JSON API for the mobile app, and a big-screen view for the stadium." With logic welded into one screen's handlers, you either duplicate the rules per view (and they will drift apart) or start passing widgets around. MVC's answer: put the rules in a Model that doesn't know screens exist, and let each View be a cheap, dumb renderer of it.

The triangle

How a request flows (ASP.NET Core MVC flavour)

The lecture slides show the Java EE version of web MVC — JSP pages as Views, a Servlet as Controller, JavaBeans/EJBs as the Model (Java EE, now Jakarta EE, is Java's enterprise platform: application servers that host these components and handle transactions, security and scaling for them). The identical idea in the C# world is ASP.NET Core MVC:

1. Request arrives — GET /products/42. The framework's router maps the URL to a controller action: ProductsController.Details(42).
2. Controller coordinates — it calls into the Model (domain services/entities): var p = _catalog.Find(42);. No HTML here, no SQL here.
3. Model does the real work — business rules run, the repository fetches data.
4. Controller picks a View — return View(p); chooses Details.cshtml and hands it the model data.
5. View renders — the Razor template turns the model into HTML. Swap it for a JSON serialiser and the same controller + model now serve a mobile API.

// VIEW — dumb renderer; subscribes to the model (Observer pattern)
public class ScoreboardView
{
    private readonly Match _match;
    public ScoreboardView(Match match)
    {
        _match = match;
        _match.Changed += Render;          // ③ model notifies view
    }
    public void Render() =>
        Console.WriteLine($"[view] SCORE {_match.Runs}/{_match.Target}" +
                          (_match.Won ? "  — WON!" : ""));
}

// CONTROLLER — translates raw input into model operations
public class MatchController
{
    private readonly Match _match;
    public MatchController(Match match) => _match = match;
    public void HandleInput(string key)    // ① input arrives here
    {
        if (key == "4") _match.AddRuns(4); // ② controller updates model
        if (key == "6") _match.AddRuns(6);
    }
}

// Wiring: var m = new Match(); new ScoreboardView(m);
// new MatchController(m).HandleInput("6");
// → [view] SCORE 6/120

How MVC relates to 3-tier (slide: "3-Tier and MVC")

Students constantly conflate these two, and the slides call the difference out explicitly:

They compose rather than compete. In a modern web app, MVC typically lives inside the tiers: the View renders in the browser (tier 1), the Controller and Model run on the app server (tier 2), and the Model persists itself via the data tier (tier 3) — that's the slides' "MVC across two tiers". In a rich single-page app, an entire MVC triangle can live in the client tier alone ("MVC — client tier" in the slides), with the server reduced to an API. So the honest answer to "is my app 3-tier or MVC?" is usually: both.

Benefits & drawbacks

Real-world examples: ASP.NET Core MVC and Razor Pages, Ruby on Rails, Django (calls it MTV, same triangle), Spring MVC, Laravel; on the desktop, cousins like MVVM (WPF's INotifyPropertyChanged binding is the "model notifies view" edge made framework-level) and MVP. Chapter 11 puts MVC, MVP and MVVM side by side.

Decentralised systems: Peer-to-Peer

Peer-to-Peer (P2P) architectural

Intent: connect nodes in an ad-hoc manner without central control — the concepts of "client" and "server" disappear because every node plays both roles interchangeably.

The problem: the central server is a bottleneck, a bill, and a target

In client–server, all load and all trust concentrate in one place. Three ways that hurts:

• Scalability: a million users downloading a 5 GB game from one server farm needs colossal bandwidth — and the more popular the file, the worse the experience.
• Availability: one outage (or DDoS attack) takes everyone down — a single point of failure.
• Control: whoever owns the server owns the system. The slides mention Napster: its file transfers were peer-to-peer, but its search index was one central server — so a court order against that one server killed the whole network in 2001. Its successors (KaZaA, Gnutella, BitTorrent) decentralised the index too, precisely to remove that single point of control.

The structure

How a request flows (BitTorrent-style file sharing)

1. Join — your node starts up and discovers a few other peers (from a lightweight tracker or a distributed hash table — see the deep dive below).
2. Query — "who has file X?" The question propagates peer-to-peer; several peers answer "I have pieces 1–40", "I have 30–80".
3. Download in parallel — you fetch different pieces from different peers simultaneously. Here you are acting as a client.
4. Upload while downloading — other peers fetch from you the pieces you already have. Now you are the server. Both roles at once — this is the defining property.
5. Seed — after completing, you keep serving. The swarm's total capacity grew because you joined: popularity makes P2P faster, the exact opposite of client–server.

Benefits & drawbacks

Real-world examples: BitTorrent (file distribution — even Windows Update and game launchers use P2P delivery between machines on a LAN); blockchain networks like Bitcoin and Ethereum (every full node stores, validates and relays the ledger — consensus without a central bank is P2P's boldest application); early Skype (calls routed through super-peers); the slides' historical examples Napster and KaZaA. Note that many "P2P" systems are hybrids: a tiny central piece for bootstrapping, a decentralised core for the heavy lifting.

Service-based architectures: SOA, Proxy/Broker, Service Locator

Service-Oriented Architecture (SOA) architectural

Intent: segment a large system's functionality into distributed services — network-accessible modules with published interfaces — register them in a registry, and compose them into business processes with an orchestrator. SOA is the direct predecessor of microservices (chapter 9).

The problem: integration spaghetti

Enterprises accumulate systems for decades: a COBOL mainframe for accounts, a 1990s CRM, a Java billing system, a new mobile backend. Each new business process ("let customers transfer funds from the app") needs several of them. The naive approach is a point-to-point integration for every pair that must talk — custom file drops, direct DB reads, bespoke sockets. With N systems you head towards N×(N−1)/2 fragile, undocumented links; nobody dares touch the mainframe because seventeen unknown things read its tables directly. The change request that kills it: "replace the CRM" — and suddenly you must find and rewrite every hidden link into it.

SOA's fix: every capability is wrapped as a service with an explicit, published contract, and consumers depend only on contracts — never on tables, files, or internals. Composition happens in one visible place instead of everywhere.

The components (per the slides)

• Distributed services — self-contained business functions exposed over the network. The slides' bank example: Registration, Authentication, Balance Inquiry, Fund Transfer. In the classic era they spoke SOAP (an XML message protocol) described by WSDL (Web Services Description Language — an XML file that machine-describes a service's operations, parameters and endpoint, so tooling can generate client code from it). REST or plain XML (POX) also appear, as slide 22 notes.
• Registry / name service — where services register themselves and consumers look them up. The era's standard was UDDI (Universal Description, Discovery and Integration — a "yellow pages" for web services). This is the Service Locator idea at enterprise scale.
• Orchestrator — connects services to realise a holistic process: transfer funds = call Authentication → Balance Inquiry → Fund Transfer, handle failures, keep an audit trail. Often implemented on an ESB (Enterprise Service Bus): middleware that routes messages between services, transforms formats (XML↔JSON↔fixed-width mainframe records) and speaks legacy protocols — which is exactly why the slides say an ESB shines for connecting heterogeneous and legacy services.

How a request flows ("transfer LKR 5,000 to Mum")

1. Consumer calls the process, not the pieces — the mobile app sends one request, TransferFunds, to the orchestrator. It has no idea four services exist.
2. Orchestrator resolves services — it consults the registry (or its cached bindings) for the current endpoints of Authentication, Balance Inquiry and Fund Transfer.
3. Authentication service — validates the user's session/token.
4. Balance Inquiry service — the ESB may here transform the request into the fixed-width record format the mainframe expects. Sufficient funds? Continue.
5. Fund Transfer service — performs the debit/credit; the orchestrator handles a failure by compensating (e.g. reversing the debit) and logging.
6. One response returns — the orchestrator aggregates results and answers the app.

// In .NET's SOA era (WCF), attributes like these generated the WSDL
// contract automatically — clients in Java or COBOL middleware could
// consume it without ever seeing your C#.
[ServiceContract]
public interface IFundTransferService
{
    [OperationContract]
    TransferResult Transfer(string fromAccount, string toAccount, decimal amount);
}

public record TransferResult(bool Success, string Reference, string? Error);

SOA vs microservices (the teaser for chapter 9)

Microservices kept SOA's core insight (business capabilities as independently deployable services behind contracts) and dropped the heavyweight middleware — the ESB had itself become a bottleneck and a single point of change. Full story in chapter 9.

Benefits & drawbacks

Real-world examples: core banking (exactly the slides' example), airline reservation ecosystems, government one-stop portals stitching decades-old departmental systems, telecom BSS/OSS stacks. In .NET, WCF + BizTalk Server was Microsoft's classic SOA toolkit.

Knowledge & event-driven patterns: Blackboard, Pub/Sub

Blackboard architectural

Intent: for problems with no deterministic solution strategy, let independent specialist knowledge sources cooperatively build a solution on a shared data structure (the blackboard), coordinated by a control component — the solution emerges incrementally rather than following a fixed pipeline.

The problem: no algorithm gets you from input to answer

Take speech recognition (the pattern's original home, the 1970s Hearsay-II system). Raw audio must become text, but every stage is uncertain: a phoneme detector produces guesses ("that sound is 70% 'b', 30% 'p'"), word hypotheses depend on phonemes and on grammar, grammar depends on words… A naive fixed pipeline — audio → phonemes → words → sentence, each stage feeding the next — breaks because information must flow both ways: recognising the word "architecture" upstream can retroactively fix a misheard phoneme downstream. The change request that kills the pipeline: "use sentence-level context to correct phoneme guesses" — a fixed one-way pipeline simply has no channel for that.

The structure (three parts, straight from the slides)

How a "request" flows (speech recognition, one cycle at a time)

1. Seed — the raw audio signal is written onto the blackboard.
2. Control scans — which knowledge sources can contribute right now? The phoneme detector can (there's a fresh signal); the grammar analyser can't yet.
3. KS activates — the phoneme detector writes hypotheses: "b-a-k…? p-a-k…?" with confidences.
4. New data enables new specialists — the word matcher now sees phonemes and writes "back (0.6), pack (0.4)".
5. Higher knowledge corrects lower — the grammar analyser sees "…sent the ___ up" and boosts "pack"; it may even revise the phoneme hypothesis. This backward correction is what pipelines can't do.
6. Control stops — when a sentence hypothesis crosses the confidence threshold (or no KS can improve anything), control declares the answer.

public class Blackboard
{
    // hypothesis name → (value, confidence)
    public Dictionary<string, (object Value, double Confidence)> Data { get; } = new();
    public bool Has(string key) => Data.ContainsKey(key);
}

public interface IKnowledgeSource
{
    string Name { get; }
    bool CanContribute(Blackboard bb);   // pattern-match the board
    void Contribute(Blackboard bb);      // write new/better hypotheses
}

public class Control
{
    private readonly List<IKnowledgeSource> _sources;
    public Control(List<IKnowledgeSource> sources) => _sources = sources;

    public void Run(Blackboard bb)
    {
        bool progress = true;
        while (progress && !Solved(bb))
        {
            // control policy: here, first eligible KS wins; real systems
            // rank candidates by expected value of their contribution
            var ks = _sources.FirstOrDefault(s => s.CanContribute(bb));
            progress = ks != null;
            if (ks != null)
            {
                Console.WriteLine($"[control] activating {ks.Name}");
                ks.Contribute(bb);
            }
        }
    }
    private bool Solved(Blackboard bb) =>
        bb.Has("sentence") && bb.Data["sentence"].Confidence > 0.9;
}

Benefits & drawbacks

Real-world examples (from the slides): speech recognition, vehicle identification and tracking, protein structure identification, sonar signal interpretation — all "AI problems" where evidence accumulates from noisy sources. Modern echoes: sensor-fusion stacks in self-driving cars and multi-agent AI systems that share a common working memory.

Publish/Subscribe (Pub/Sub) architectural

Intent: publishers broadcast messages on named topics (subjects) to a broker (messaging server / middleware); subscribers tell the broker which topics interest them. Publishers and subscribers never know each other — they are decoupled in space, time, and synchronisation.

The problem: the publisher that knows everybody

public class OrderService
{
    private readonly InventoryService _inventory;
    private readonly BillingService _billing;
    private readonly EmailService _email;
    // next sprint: + AnalyticsService, + FraudCheck, ...

    public void PlaceOrder(Order order)
    {
        Save(order);
        _inventory.Reserve(order);   // blocks until done
        _billing.Charge(order);      // blocks until done
        _email.SendReceipt(order);   // email server down? order fails!
    }
}

public class OrderService
{
    private readonly IMessageBroker _broker;
    public OrderService(IMessageBroker broker) => _broker = broker;

    public void PlaceOrder(Order order)
    {
        Save(order);
        _broker.Publish("orders.placed", order.ToJson());
        // done. Zero knowledge of who listens. Adding an
        // analytics consumer = a new subscription, not an edit here.
    }
}

The change request that kills the naive version: "add fraud detection, a loyalty points service, and a warehouse dashboard — and by the way, the email service being down must not stop order placement." Direct calls mean editing OrderService for every new consumer (an OCP violation at system scale) and coupling its uptime to all of theirs. Pub/Sub inverts the dependency: consumers opt in, the publisher just announces facts.

The structure

How a message flows

1. Subscribe — Billing and Email each tell the broker "I want orders". The broker records the subscriptions; publishers are not involved and may not even exist yet (time decoupling).
2. Publish — OrderService sends {orderId: 42, ...} to topic orders and immediately continues. It doesn't block, doesn't retry per-consumer, doesn't know the count of listeners (space + synchronisation decoupling).
3. Broker fans out — it delivers a copy to every current subscriber of orders. A durable subscription is even held for subscribers that are temporarily offline — they catch up on reconnect.
4. Subscribers react independently — Billing charges the card, Email sends the receipt. One of them crashing affects nobody else.
5. New consumer? No code changes upstream — the Dashboard team subscribes to orders next month; OrderService is never edited or redeployed.

public interface IMessageBroker
{
    void Subscribe(string topic, string name, Action<string> handler);
    void Publish(string topic, string message);
}

public class MessageBroker : IMessageBroker
{
    private readonly Dictionary<string, List<(string Name, Action<string> Handler)>>
        _topics = new();

    public void Subscribe(string topic, string name, Action<string> handler)
    {
        if (!_topics.TryGetValue(topic, out var subs))
            _topics[topic] = subs = new();
        subs.Add((name, handler));
    }

    public void Publish(string topic, string message)
    {
        if (!_topics.TryGetValue(topic, out var subs)) return; // nobody cares — fine!
        foreach (var (name, handler) in subs)
        {
            Console.WriteLine($"[broker] {topic} → {name}");
            handler(message);   // a real broker queues this asynchronously
        }
    }
}

Benefits & drawbacks

Real-world examples: the slides list the classic broker products — JMS (Java Messaging Service — Java EE's standard pub/sub API), RabbitMQ, TIBCO, IBM MQ Series, BizTalk — and the classic scenarios: a stock exchange feed (one price tick published, thousands of trading systems each subscribed to the symbols they care about) and IoT (thousands of sensors publish readings over MQTT, a lightweight pub/sub protocol; dashboards, alarms and loggers subscribe). Also: event notifications, distributed caching & logging, live chat and multiplayer collaboration. Modern .NET equivalents: Azure Service Bus topics, Kafka with confluent-dotnet, Redis pub/sub, and in-process, MediatR notifications or C# events.

Proxy / Broker architectural

Intent: let a client call a remote service as if it were a local object. The service publishes a proxy (a local stand-in implementing the same interface) to a look-up service; the client downloads the proxy and calls methods on it; the proxy handles all the networking — marshalling arguments, sending them to the real implementation, returning results. The broker is the middleman infrastructure making this work.

The problem: remote calls are nothing like local calls

Suppose your client needs GetBalance("ACC-42") from a service on another machine. Naively you'd hand-write socket code in the client: open a TCP connection, invent a wire format ("GETBAL|ACC-42\n"), serialise arguments, parse responses, handle timeouts — for every method of every service, duplicated in every client. The change request that kills it: "add a parameter to GetBalance" — now every hand-rolled client is silently broken, and the compiler can't warn anyone because the contract only exists as string conventions. The fix: define the contract once as an interface, and let generated proxies do the plumbing, checked by the type system.

The mechanism (the slides' five steps)

1. Define the service with an interface — e.g. IAccountService. The interface is the contract.
2. Create a proxy of that interface for the given implementation — typically generated, not hand-written.
3. Upload the proxy to a look-up service — the server registers "I implement IAccountService, here's the proxy/stub for reaching me".
4. Client downloads the proxy from the look-up service (this is where Service Locator comes in — the slides note the two patterns complement each other).
5. Client calls the proxy like a local object — the proxy marshals the call, ships it across the network to the real implementation, and unmarshals the result.

// The contract — shared by client and server
public interface IAccountService
{
    decimal GetBalance(string accountNo);
}

// Client side: same interface, but the body is plumbing.
// (Tools generate this: RMI stubs, CORBA, WCF svcutil, gRPC codegen.)
public class AccountServiceProxy : IAccountService
{
    private readonly string _endpoint;
    public AccountServiceProxy(string endpoint) => _endpoint = endpoint;

    public decimal GetBalance(string accountNo)
    {
        Console.WriteLine($"[proxy] marshal GetBalance({accountNo})");
        Console.WriteLine($"[proxy] → send to {_endpoint}, wait for reply");
        // real proxy: serialize → TCP/HTTP → server skeleton invokes
        // the actual AccountService → result serialized back
        return 1250.75m; // demo stand-in for the unmarshalled reply
    }
}

// Client code cannot tell it's remote:
// IAccountService svc = registry.Lookup<IAccountService>();
// Console.WriteLine(svc.GetBalance("ACC-42"));

Session Facade (the slides' J2EE special case)

The slides add a related idea from the Java EE world: a session facade — a stateless session bean that sits in front of a cluster of fine-grained entity beans (persistent objects). Remote clients call one coarse method on the facade (TransferFunds(from, to, amount)) instead of making many fine-grained remote calls (getAccount, getBalance, setBalance…). Two wins: the client sees a simpler interface with the implementation complexity hidden — that's the Facade pattern — and you replace N slow network round-trips with one. The modern .NET equivalent is an API controller or application-service class exposing one endpoint per use case, not per entity property.

Benefits & drawbacks

Real-world examples: the slides' Java RMI and CORBA (the 1990s cross-language broker standard); .NET Remoting and WCF client proxies; today's gRPC generated clients — same pattern, protobuf-flavoured.

Service Locator architectural

Intent: distributed services register themselves in a central registry; clients look up the service they need by name or type instead of hard-coding where (or what) it is. This gives location transparency — the client doesn't know or care which machine serves it.

The problem: hard-wired locations and constructions

In a distributed system, writing new TcpClient("192.168.1.40", 9000) in the client welds it to one machine. The change request that kills it: "we moved the payments service to new hardware" (or "we now run three instances") — every client needs a code change and redeployment. The slides' cure: services register themselves in a registry — JNDI (Java's naming directory), the RMI Registry, UDDI, the CORBA naming service — and clients resolve at runtime:

1. Service starts → registers — "I am IPaymentService, reach me at host X, port Y."
2. Client asks the locator — "give me an IPaymentService." No address in client code.
3. Locator consults the registry (and typically caches the answer) and hands back a reference — often a proxy; the two patterns complement each other.
4. Client calls the service through the returned reference, oblivious to its location. Tomorrow the registry can point somewhere else; the client never changes.

public static class ServiceLocator
{
    private static readonly Dictionary<Type, object> _services = new();

    public static void Register<T>(T implementation) where T : class
        => _services[typeof(T)] = implementation;

    public static T Resolve<T>() where T : class
        => _services.TryGetValue(typeof(T), out var s)
             ? (T)s
             : throw new InvalidOperationException(
                   $"No service registered for {typeof(T).Name}");
}

// Startup:  ServiceLocator.Register<IPaymentService>(new StripePayments());
// Anywhere: var pay = ServiceLocator.Resolve<IPaymentService>();

The "Service Locator is an anti-pattern" debate — both sides, fairly

Modern .NET advice says: don't use the in-process locator above; use dependency injection (DI) instead — the technique where a container passes dependencies into constructors, which you met with DIP. Why did DI win?

public class CheckoutService
{
    public Receipt Checkout(Cart cart)
    {
        // Nothing in this class's signature reveals
        // these needs — you find out by reading bodies:
        var pay = ServiceLocator.Resolve<IPaymentService>();
        var tax = ServiceLocator.Resolve<ITaxCalculator>();
        // forgot to Register ITaxCalculator in a test?
        // → runtime explosion, not compile error
        ...
    }
}

public class CheckoutService
{
    private readonly IPaymentService _pay;
    private readonly ITaxCalculator _tax;

    // The constructor IS the honest list of needs.
    // Forget one? The compiler / container tells you
    // at startup, not mid-request.
    public CheckoutService(IPaymentService pay,
                           ITaxCalculator tax)
        => (_pay, _tax) = (pay, tax);
}

The fair verdict: the anti-pattern criticism (popularised by Mark Seemann) targets using a locator inside application classes as a lazy substitute for DI — there it genuinely hides dependencies and hurts testability. But the pattern is not universally bad: (1) in its original, distributed sense — finding remote services via a registry — it's alive and essential: microservice service discovery (Consul, Eureka, Kubernetes DNS, chapter 9) is exactly Service Locator at network scale; (2) DI containers themselves use locator-style resolution internally (IServiceProvider.GetService() in ASP.NET Core is a service locator — the guidance is that the framework may call it, your business classes shouldn't); (3) at genuine framework boundaries (plugin hosts, middleware activation) a lookup is sometimes the only option. Rule of thumb: resolve at the composition root, inject everywhere else.

Benefits & drawbacks

Real-world examples: JNDI and the RMI registry (slides), UDDI in SOA, DNS itself (name → address is the ur-locator), Kubernetes service DNS, Consul/Eureka in microservices, and IServiceProvider in ASP.NET Core.

Cluster architectures

Clustering, load balancing & failover architectural

Intent: run multiple identical copies of a tier on separate machines behind a load balancer, so the system survives machine failures (failover) and scales by adding boxes (horizontal scaling).

The problem: one machine = one failure away from an outage

Your 3-tier app runs on one app server. Two guaranteed disasters: (1) the machine dies — or just needs an OS patch — and the whole business is down; (2) traffic exceeds what one machine can do, and the only lever is buying an ever-bigger machine, which gets exponentially expensive and still has a ceiling. The change request that kills it: "we need 99.9% uptime and zero-downtime deployments." A single node can't do either, however big. The fix is redundancy: clones + a traffic director.

The moving parts

• Load balancer — the single entry point that spreads requests across nodes. Strategies: round-robin (take turns), least connections (send to the idlest), IP-hash / sticky sessions (same client → same node). It health-checks nodes (heartbeat pings) and stops routing to a dead one within seconds — that's failover.
• Nodes — identical instances of the tier. Identical is the key word: any node must be able to serve any request, which forces you to deal with…
• Session state — if node A holds your shopping cart in memory and node A dies, your cart dies too. Solutions: sticky sessions (pin the user to one node — simple, but state is lost on failure), session replication (nodes copy state to each other), or best: keep nodes stateless and store session state in a shared cache (Redis/SQL) so any node can pick up any request.

Single-tier vs multi-tier clustering (the slides' two diagrams)

Single-tier clustering clones the whole (web+app) server — simple, few machines, fine for moderate scale, but you must scale everything together even if only one layer is busy. Multi-tier clustering gives each tier its own cluster and balancer — the web tier might need 8 nodes while the app tier needs 3; each scales and fails over independently, firewalls can sit between tiers (security), but you now run a fleet. This is n-tier + clustering composed — and one step from here is chapter 9's microservices, where each service is its own little cluster.

How a request flows (including a failure!)

1. Client → load balancer — clients only ever know the balancer's address (one DNS name).
2. Health check — the balancer's heartbeat noticed 10 seconds ago that Node B stopped answering; B is out of the rotation.
3. Route — round-robin picks the next healthy node, say A. If sessions are sticky, your cookie pins you to A instead.
4. Node A serves the request — reading any session state from the shared store, so it doesn't matter that your last request went to C.
5. Response returns via the balancer — the user never learns that B died. That's failover: failure without downtime.

Watch exactly this scenario in the Request Tracer — pick "Cluster (failover)".

Benefits & drawbacks (slides list the benefits)

Real-world examples: every serious website is a web farm behind NGINX/HAProxy or a cloud balancer (AWS ELB, Azure Load Balancer); SQL Server Always On availability groups and Redis Sentinel for the data tier; Kubernetes Deployment replicas + Service are exactly "cluster + load balancer + health checks" turned into declarative configuration.

Interactive: the Request Tracer

Reading about request flows is one thing — watching them is better. Pick an architecture, press Send request, and follow one request hop-by-hop through the boxes. The same user click takes a very different journey depending on the architecture you chose.

Choosing an architecture

Every pattern buys some quality attributes and pays with others. This table is the whole chapter in one look — read each row as "if these are my dominant forces, start here":

Check yourself — which architecture fits?

Next up: SOA's successor gets its own two chapters — how microservices decompose a monolith, and what it costs. And when patterns on this page start blurring together (Observer vs Pub/Sub? Broker vs Proxy vs Facade?), chapter 12 untangles them side by side.