For interoperability reasons, most distributed computing has been INTRA-ORGANISATIONAL — inside one organisation, where local standards and management practices can be applied and where one administrator controls everything. INTER-ORGANISATIONAL COMPUTING crosses that boundary. The motivations: · access to SPECIALIST CAPABILITY you cannot economically build — payment processing, mapping, identity verification, machine translation · access to DATA only the other organisation holds — a national ID register, a credit bureau, a weather service · REGULATORY REQUIREMENT — a licence system may be obliged to report to a police records system · COST — renting capability by the call rather than building, staffing and operating it · SPEED TO MARKET — integration in days rather than a project in quarters WHAT CHANGES WHEN YOU CROSS THE BOUNDARY — and every item is an architectural constraint, not an administrative detail: NO SHARED ADMINISTRATION you cannot restart their server, read their logs, or see their deploy schedule NO SHARED TRUST their data must be validated; your data must be protected in transit and at rest on their side UNILATERAL CHANGE they can deprecate the API you depend on, with notice you did not agree DIFFERENT AVAILABILITY their 99.5% becomes your ceiling TARGETS unless you design around it LEGAL AND COMMERCIAL a contract and an SLA now sit OVERLAY between two pieces of software RATE LIMITS AND QUOTAS capacity is bought, not provisioned THE ARCHITECTURAL CONSEQUENCE: every external dependency must be treated as a component that WILL fail, WILL be slow, and WILL change — because you have no authority over any of those.

PEER-TO-PEER (p2p) SYSTEMS are decentralised systems where computations may be carried out by any node on the network. The overall system is designed to take advantage of the computational power and storage of a large number of networked computers. Most p2p systems have been personal systems, but there is increasing business use. In principle, in a p2p system EVERY NODE COULD BE AWARE OF EVERY OTHER NODE, could make connections and could exchange data. In practice this is impossible at scale, so nodes are organised in LOCALITIES with some nodes acting as BRIDGES. TWO LOGICAL ARCHITECTURES: DECENTRALISED p2p ARCHITECTURE · no central node; searches and requests propagate node-to-node through the network · a node knows only its neighbours · MAXIMALLY ROBUST — there is nothing to take down, and no single point of failure or control · BUT: searching is slow and expensive, because a query may have to flood a large portion of the network, and there is no guarantee a resource is found even if it exists n1 ── n2 ── n3 │ ╲ │ ╱ │ n4 ── n5 ── n6 SEMI-CENTRALISED p2p ARCHITECTURE · one or more nodes act as ARBITERS or INDEXES, coordinating the interaction between peers · the index tells a peer where to find a resource; the actual data transfer is still peer to peer · MUCH FASTER SEARCH, and predictable · BUT: the index is a single point of failure — and, in practice, a single point of legal and regulatory attack. The history of file-sharing systems is precisely the history of this trade-off: centralised indexes were shut down; fully decentralised ones were not. n1 n2 n3 ╲ │ ╱ ┌───▼───┐ │ index │ └───┬───┘ ╱ │ ╲ n4 n5 n6 WHERE p2p IS THE RIGHT CHOICE: · the resource being shared is naturally distributed (bandwidth, storage, idle CPU) · demand is bursty and the load scales with the number of participants — every new peer brings capacity as well as demand, which is p2p's unique property · censorship resistance or the absence of a controlling party is a requirement EXAMPLES: BitTorrent (bulk distribution — more downloaders means more seeders), blockchain networks, distributed hash tables, some CDN edge designs, IP telephony.

SERVICE-ORIENTED ARCHITECTURE (SOA) is built around the concept of a reusable, independent WEB SERVICE — the standard answer to inter-organisational computing. A WEB SERVICE is a loosely coupled, reusable software component that encapsulates discrete functionality, which may be distributed and programmatically accessed. A web service is a service accessed using STANDARD INTERNET AND XML-BASED PROTOCOLS. THE ESSENTIAL POINT: a service provider and a service user need never negotiate about what the service does. It is defined, published and used through open standards, so integration requires no agreement between the two organisations' engineers beyond reading the specification. THE CLASSIC WEB-SERVICE STANDARDS STACK: SOAP a message-exchange standard supporting service communication WSDL the Web Service Definition Language — defines the interface: the operations, their parameters, and how the service is accessed UDDI a discovery standard defining how service description information can be organised so that potential users can find a service (all built on XML, and on HTTP as the transport) KEY BENEFITS OF SOA · services can be provided LOCALLY OR OUTSOURCED to external providers, and the consumer need not care which · services are LANGUAGE-INDEPENDENT — a Java client can call a .NET service, which was the original motivating problem · INVESTMENT IN LEGACY SYSTEMS CAN BE PRESERVED: an existing system can be wrapped and exposed as a service rather than replaced · INTER-ORGANISATIONAL COMPUTING is facilitated through simplified information exchange · the platform for constructing new services by COMPOSING existing ones SERVICE COMPOSITION / ORCHESTRATION: because services are independent and standard, a new business process can be built by wiring several together — often with no new business logic at all. This is the architectural pay-off of SOA, and it is what makes "assemble rather than build" credible. REST — the modern successor to the SOAP stack. Rather than a message-passing protocol over HTTP, REST uses HTTP itself: resources identified by URLs, manipulated with the HTTP verbs (GET, POST, PUT, DELETE), representations usually in JSON. It won because it is dramatically simpler, cacheable by existing web infrastructure, and readable without tooling. The architectural idea — self-describing, standard-protocol, loosely coupled services — is the same.

THE PRACTICAL HEART OF THIS TOPIC. Take one external dependency and work out what it does to your system. THE SETUP: the licence system calls the National ID Service to verify an applicant's identity. their published SLA: 99.5% availability, p95 800 ms your requirement: 99.9% availability, p95 2 s CHECK 1 — WHAT DOES THEIR AVAILABILITY DO TO YOURS? For components in SERIES (both must work), availabilities multiply: A_total = A_yours × A_theirs = 0.999 × 0.995 = 0.994005 → 99.40% YOU HAVE JUST MISSED YOUR OWN TARGET, and you did nothing wrong. Downtime per 30-day month: target 99.9% → 43.2 minutes actual 99.40% → 0.005995 × 43,200 min = 259 min ≈ 4.3 h A SIX-FOLD INCREASE IN DOWNTIME from one dependency. ADD A SECOND EXTERNAL DEPENDENCY at 99.5% (say a payment gateway) and it gets worse: 0.999 × 0.995 × 0.995 = 0.989035 → 98.90% downtime = 0.010965 × 43,200 = 474 min ≈ 7.9 h/month SERIES DEPENDENCIES COMPOUND. Three 99.5% services in your critical path put a ~98.5% ceiling on you no matter how good your own code is. CHECK 2 — WHAT DOES THEIR LATENCY DO TO YOURS? Your own p95 budget is 2,000 ms. Their p95 is 800 ms, so 40% of your entire budget is spent waiting for someone else. And percentiles do not simply add: if you call them TWICE in one request, the probability that at least one call is above their p95 is 1 − 0.95² = 9.75% so your p95 is now governed by their p90-ish behaviour, and your tail gets much worse. THE RULE: minimise the number of external calls per request, and never loop over one. THE FOUR DESIGN RESPONSES, in order of value: 1. GET THEM OFF THE CRITICAL PATH. Does identity verification have to happen while the officer waits? If it can be asynchronous — verify after submission, flag mismatches for review — then their outage delays a background job instead of stopping counter service. THIS IS THE HIGHEST-VALUE MOVE, and it is an architectural decision, not a coding one. Recall the licence use case from the requirements topic: extension 3a said "if the ID service is unreachable, the officer may proceed with a manual check". That extension was this design decision, discovered during elicitation. 2. TIMEOUT AND CIRCUIT-BREAK. Set an explicit timeout well below your own budget (say 1,500 ms). Without one, your threads block on their hang and your system fails too — this is how one dependency's slowness becomes your outage. A CIRCUIT BREAKER stops calling after N consecutive failures and fails fast, then probes periodically to recover. 3. CACHE AND DEGRADE GRACEFULLY. An identity verified yesterday is probably still valid. Serving a cached result during their outage converts a hard failure into a slightly stale success. Decide explicitly what the system does when the dependency is unavailable — the default of "throw an exception to the user" is a decision by omission. 4. RETRY, WITH EXPONENTIAL BACKOFF AND JITTER — AND IDEMPOTENCY. Retries help with transient failure and HURT with overload: everyone retrying at once is a thundering herd that keeps a recovering service down. Backoff plus random jitter spreads the load. And a retry is only safe if the operation is IDEMPOTENT — which is why the interface specification topic insisted on an idempotency rule. WHAT THE COMBINED DESIGN ACHIEVES: With verification moved off the critical path, the external service's availability no longer multiplies into yours at all — it affects a queue depth instead of a page load. That single restructuring is worth more than every retry and cache setting combined, which is why it is listed first.