Leer en español · Lire en français · Auf Deutsch lesen

Software architecture glossary

Short definitions of the 914 terms used in the published chapters, each linked to the chapter that explains it.

0–9

4+1 view model: Philippe Kruchten's 1995 approach that describes a system through logical, process, development and physical views, tied together by a small set of scenarios. Chapter 4

A

Abstraction: A simplified view of something that keeps what matters for a purpose and omits the rest, such as a 'file' that hides disks, sectors and caching. Chapter 3
Abstractness (A): Martin's metric: the number of abstract classes and interfaces in a component divided by its total number of classes, from 0 (fully concrete) to 1 (fully abstract). Chapter 3
Access token: A short-lived credential, issued after a user or application signs in, that is sent with each API request to prove what the caller may do. Chapter 0
Accessibility: The degree to which people with disabilities, including those using assistive technologies such as screen readers, can use a product. Chapter 2
Accidental complexity: Complexity introduced by the way a solution is built (tools, structure, workarounds) rather than by the problem. It can in principle be removed. Chapter 3
ACID: Atomicity, consistency, isolation, durability: the guarantees a database transaction provides so that data stays correct despite crashes and simultaneous users. Chapter 0
ACM Code of Ethics: The Association for Computing Machinery's Code of Ethics and Professional Conduct, updated in 2018, whose principles include contributing to society, avoiding harm, honesty, fairness, privacy and confidentiality. Chapter 11
Active-active (multi-site): An arrangement in which two or more regions serve live traffic at the same time, so losing one region needs no failover, only redistribution of traffic. Chapter 10
Activity diagram: A UML diagram showing a workflow as actions, decisions, parallel forks and joins, often divided into swimlanes for who does what. Chapter 4
Acyclic Dependencies Principle: Robert C. Martin's principle that the dependency graph between components must contain no cycles. Chapter 3
Adapter: Code that translates between a port and a specific technology, such as an HTTP controller, a SQL repository or a payment provider's SDK. One port can have many adapters. Chapter 5
Advice process: A decentralised way of making decisions in which anyone may decide, provided they first seek advice from those affected and from relevant experts. Chapter 4
Afferent coupling (Ca): The number of things outside a component that depend on it: its incoming dependencies. High Ca means many others are affected if it changes. Chapter 3
Agent: A system in which a model repeatedly chooses actions, such as tool calls, observes the results and decides what to do next until a goal is met or a limit is reached. Chapter 12
Aggregate: A cluster of domain objects changed as one unit through a single root entity, which enforces the rules that must always hold for the cluster. Chapter 5
Agile: A family of approaches to software development, set out in the 2001 Agile Manifesto, that deliver working software in short cycles and adapt plans based on feedback. Chapter 0
AI gateway: A component between applications and model providers that centralises credentials, routing, fallbacks, quotas, logging and policy checks for model calls. Chapter 12
Algorithm: A precise, step-by-step method for solving a problem, such as sorting a list or finding the shortest route, that always finishes. Chapter 0
Algorithmic bias: Systematically worse outcomes from an automated system for some groups of people, caused by data, design or the context of use. Chapter 12
Allocation view: A view that maps software onto things outside it: infrastructure (deployment), files and builds (implementation) or teams (work assignment). Chapter 4
Amdahl's law: A formula (Gene Amdahl, 1967) showing that the speed-up from adding processors is limited by the part of the work that must run serially. Chapter 2
Anomaly (phenomenon): A wrong result caused by concurrent transactions interfering, such as a dirty read, lost update or write skew; isolation levels are defined by which anomalies they prevent. Chapter 7
Anonymisation: Processing data so that it no longer relates to an identifiable person by any means reasonably likely to be used; truly anonymous data falls outside the GDPR. Chapter 8
Anti-corruption layer: A translation layer, from domain-driven design, that converts between another system's model and your own, so that the other model's concepts and quirks do not leak into your code. Chapter 11
Anti-pattern: A commonly used solution that looks reasonable but reliably causes more problems than it solves. Chapter 5
Anticorruption layer: A translation layer that a downstream context builds so that another context's or system's model cannot leak into its own. Chapter 5
Anycast: Announcing the same IP address from many locations, so that the internet's routing delivers each user's packets to the nearest location announcing it. Chapter 9
API (application programming interface): A defined set of operations, inputs and outputs through which one piece of software uses another, without needing to know how it works inside. Chapter 0
API contract: The documented promise an API makes: which requests it accepts, what each returns, which errors can occur and what will not change without notice. Chapter 0
API gateway: A single entry point in front of services that handles cross-cutting concerns such as TLS, authentication, rate limiting and routing. Chapter 6
API key: A long secret string that identifies the calling application to an API. Anyone holding the key can act as that application, so it must be kept secret. Chapter 0
API versioning: Publishing changes to an API under a new version identifier, such as /v2/, while keeping the old version working for a period so that clients can move over in their own time. Chapter 0
Approximate nearest-neighbour search: Finding the vectors closest to a query vector quickly by using an index that trades a little recall for large gains in speed. Chapter 12
arc42: A free, twelve-section template for documenting and communicating software architecture, created by Gernot Starke and Peter Hruschka. Chapter 4
Architect elevator: Gregor Hohpe's image of the architect as someone who rides between an organisation's penthouse (strategy and executives) and its engine room (code and infrastructure), connecting the two. Chapter 11
Architectural approach: A significant design decision or combination of decisions, such as a style, pattern or tactic, that the architecture uses to achieve a quality: for example an event broker with an outbox, or a warm standby region. Chapter 11
Architectural debt: Technical debt in the structure of a system, such as wrong boundaries, a shared database or cyclic dependencies, which is costly to repay because it touches many parts. Chapter 1
Architectural driver: A goal, quality attribute requirement or constraint that significantly shapes the architecture. Chapter 2
Architectural pattern: A documented, reusable solution to a recurring structural problem in a stated context, naming the parts, their responsibilities and how they relate. Often used as a synonym for style. Chapter 5
Architectural runway: In the Scaled Agile Framework, the existing code, components and infrastructure needed to implement near-term features without excessive redesign and delay. Chapter 1
Architectural style: A named family of architectures defined by the kinds of element and connector it uses and the constraints on how they may be combined, such as layered or pipes and filters. Chapter 5
Architecturally significant: Describes a decision or requirement that is expensive to change later, affects many parts of a system, or determines a key quality attribute. Chapter 1
Architecturally significant requirement (ASR): A requirement that has a measurable effect on a system's architecture: if it changed, the structure would have to change. Most ASRs are quality attributes or constraints. Chapter 2
Architecture advisory forum: A regular, open meeting where proposed decisions, spikes and their advice are discussed. It offers advice and visibility but does not itself decide. Chapter 11
Architecture characteristic: Richards and Ford's term for a quality attribute the architecture must support, such as scalability, deployability or fault tolerance. Chapter 5
Architecture Decision Record (ADR): A short document recording one significant decision: its context, the options considered, the decision, its status and its consequences. Chapter 1
Architecture description: A work product (documents, diagrams, models, decision records) that expresses an architecture. The architecture exists whether or not it is described; the description is how people share it. Chapter 1
Architecture description framework: In ISO/IEC/IEEE 42010:2022, an established set of conventions for producing architecture descriptions, such as viewpoints, templates and rules. Chapter 4
Architecture drift: Changes made without awareness of the intended architecture which, while not breaking explicit rules, move the system away from it and blur its concepts. Chapter 1
Architecture erosion: The gradual degradation of a system as changes violate its intended architecture, for example by bypassing layers or adding forbidden dependencies. Chapter 1
Architecture evaluation: A structured examination of an architecture, before or after it is built, to find out whether its decisions will let the system meet its business goals and quality requirements, and where they put those goals at risk. Chapter 11
Architecture governance: The practices by which an organisation makes sure significant technical decisions are made well, are consistent with its goals and are actually followed, including who decides, how and with what checks. Chapter 11
Architecture kata: A practice exercise created by Ted Neward in which small teams design an architecture for a short, deliberately incomplete brief, then present and defend it to their peers. Chapter 11
Architecture principle: A durable rule that guides architectural decisions, written in TOGAF style with a name, a statement, a rationale and its implications. Chapter 11
Architecture quantum: An independently deployable part of a system with high functional cohesion, including everything it needs to run, such as its database; the scope within which one set of architecture characteristics applies. Chapter 5
Architecture review board: A standing group of senior architects that reviews and approves significant designs, usually at set points in a project. It can add independent judgement but often becomes a slow gate. Chapter 11
Architecture sinkhole: An anti-pattern in layered systems where requests pass through layers that only forward them, adding code and delay without adding behaviour. Chapter 5
Architecture test: An automated test that fails the build when code breaks a structural rule, such as a forbidden dependency between layers or modules; tools include ArchUnit and import-linter. Chapter 5
Artefact repository: A store for built, versioned outputs such as container images and packages, from which every environment deploys the same file. Chapter 10
Asymmetric (public-key) cryptography: Cryptography with a key pair: a public key that anyone may hold and a private key kept secret; used for key exchange, digital signatures and certificates. Chapter 8
AsyncAPI: A machine-readable specification for describing message-driven APIs: the channels, the operations that send or receive on them and the message schemas. Chapter 6
Asynchronous communication: An interaction in which the sender hands a message to an intermediary, such as a message broker, and carries on without waiting; the receiver processes it when ready. Chapter 6
Asynchronous messaging: Communication in which the sender puts a message somewhere for the receiver to process later, and carries on without waiting for a reply. Chapter 0
At-least-once delivery: A guarantee that every message is processed, possibly more than once; duplicates must be handled by the receiver. Chapter 6
ATAM (Architecture Tradeoff Analysis Method): The SEI's scenario-based evaluation method (Kazman, Klein and Clements, 2000). In nine steps over two meetings it relates business drivers and prioritised scenarios to architectural approaches and produces risks, non-risks, sensitivity points, trade-off points and risk themes. Chapter 11
Atomic fitness function: A fitness function that checks one architectural characteristic in a single context, such as a test that forbids imports between two packages. Chapter 11
Attack surface: The sum of the points where an attacker can try to enter data into, extract data from or otherwise interact with a system: endpoints, ports, files, queues, admin tools and the people and code it trusts. Chapter 8
Attack tree: A tree whose root is an attacker's goal and whose children are the alternative (OR) or combined (AND) ways of reaching it, popularised by Bruce Schneier in 1999. Chapter 8
Attribute-based access control (ABAC): Deciding access by evaluating a policy over attributes of the user, the resource, the action and the context, such as country, data classification or time of day. Chapter 8
Audit trail: A complete, chronological and tamper-evident record of defined actions, showing who did what and when, kept to establish accountability. Chapter 8
Authentication: Verifying that a user or system is who or what it claims to be, for example by a password, a passkey or a certificate. Chapter 8
Authorisation: Deciding whether an authenticated user or system is allowed to perform a particular action on a particular resource. Chapter 8
Automated canary analysis: Statistical comparison of a canary's metrics with those of a baseline running the old version, used by the pipeline to promote or roll back without a human judgement. Chapter 10
Automation bias: The tendency of people to accept an automated system's recommendations without enough scrutiny, even when they are wrong. Chapter 12
Autoscaling: Automatically changing the number of instances as load changes, reactively from a metric, on a schedule, or predictively from a forecast. Chapter 9
Availability: The proportion of time, or of requests, for which a system is ready to deliver its service when asked, usually written as a percentage such as 99.9%. Chapter 2
Availability zone: One of several physically separate groups of data centres within a cloud region, each with independent power, cooling and networking, close enough for fast connections. Chapter 0

B

Back pressure: A way for a slow consumer to make a fast producer slow down, instead of letting buffers and queues grow without limit. Chapter 5
Backend as a service (BaaS): Fully managed third-party services, such as authentication, databases, storage and messaging, that replace server-side components an organisation would otherwise build and run. Chapter 6
Backend for frontend (BFF): A server-side API built for one kind of client, such as the mobile app, so that each client gets operations and data shaped for its own needs. Chapter 3
Backend for frontend (BFF): A thin back end built for one kind of client, such as the mobile app, which calls services and shapes their data for that client. Chapter 6
Backfill: Filling a new column or table with values for existing rows, usually in small batches so that the live system is not disrupted. Chapter 7
Background worker: A process that takes slow or bursty jobs, such as emails or reports, from a queue and processes them outside the request that created them. Chapter 5
Backing service: Any service an application uses over the network, such as a database, queue, cache or email API, treated as an attached resource that configuration can swap. Chapter 10
Backup: A copy of data kept separately from the original so that it can be restored after loss, corruption or deletion. Chapter 0
Backward compatibility: A schema change is backward compatible when code using the new schema can still read data written with the old one. Chapter 7
Backward-compatible change: A change to an interface or schema that existing consumers can survive without modification, such as adding an optional field. Removing or renaming a field is a breaking change. Chapter 6
Bandwidth: How much data a connection can carry per second, such as 100 megabits per second. High bandwidth does not reduce latency. Chapter 0
Batch inference: Processing many model requests together, asynchronously, at lower cost per request but with a longer wait for results. Chapter 12
Batch processing: Processing a bounded set of data in one run, such as all of yesterday's orders, and finishing. Chapter 5
Behavioural subtyping: The rule behind Liskov substitution: a subtype may not demand more from callers (stronger preconditions), promise less (weaker postconditions) or break the supertype's invariants. Chapter 3
Big ball of mud: A system with no recognisable structure, in which almost everything depends on everything else; the name comes from Brian Foote and Joseph Yoder (1997). Chapter 5
Big design up front (BDUF): An approach in which the architecture and design are completed in detail before implementation starts. Chapter 1
Big-bang rewrite: Replacing a system by building a new one from scratch and switching over all at once; widely regarded as high risk because value arrives only at the end and hidden behaviour is easily lost. Chapter 11
Big-O notation: A way of describing how the work an algorithm does grows as the amount of data grows, for example O(n) for linear growth or O(1) for constant time. Chapter 0
Binding time: The moment at which a decision is fixed: when code is written, at build, at deployment, at start-up or while the system runs. Chapter 2
Bit: A binary digit, 0 or 1: the smallest unit of information a computer stores. Chapter 0
Blameless culture: An approach in which people who were involved in an incident can describe what they did and why without fear of punishment, so the organisation learns how the system really works. Chapter 9
Blast radius: How much of the system and how many users a failure, change or experiment can affect; chaos experiments deliberately keep it small. Chapter 9
Blue-green deployment: Running two complete production environments and switching all traffic from the old one (blue) to the new one (green) at once, keeping the old one ready for an instant switch back. Chapter 10
BM25: A classic keyword ranking function that scores documents by how often they contain the query's terms, weighting rare terms more and normalising for document length. Chapter 12
Bounded context: An explicit boundary within which one domain model and its ubiquitous language apply consistently; outside it, the same words may mean something else. Chapter 5
Branch: A separate line of development in version control, used to work on a change without affecting the main line until it is ready to merge. Chapter 0
Branch by abstraction: A technique for large changes inside one codebase: put an abstraction in front of the part to be replaced, move callers to it, build the new implementation behind it, switch over and remove the old one, keeping the system releasable throughout. Chapter 11
Breaking change: A change to an API that makes existing, correct client code stop working, such as renaming or removing a field. Chapter 0
Breakpoint test: A performance test that increases load steadily until the system breaks, to find its maximum capacity and its first bottleneck. Chapter 9
Broker topology: An event-driven topology with no central coordinator: processors react to events and publish further events, so the workflow emerges from their reactions. Chapter 6
Bug: A mistake in software that makes it behave differently from what was intended, from a crash to a silently wrong answer. Chapter 0
Bug bounty: A programme that pays outside researchers for reporting valid security vulnerabilities through an agreed process. Chapter 8
Build once, deploy many: The rule that a change is built into one immutable artefact exactly once, and that same artefact is promoted through every environment with only configuration differing. Chapter 10
Build, release, run: The strict separation of turning code into an artefact (build), combining it with an environment's configuration (release) and executing it (run). Chapter 10
Building block: In arc42, any part of a system's static structure, such as a subsystem, service, component or module, shown in the building block view. Chapter 4
Bulkhead: Partitioning resources such as thread pools, connection pools or instances, so that a failure or overload in one part cannot consume the resources of the others. Chapter 9
Burn rate: How fast an error budget is being spent relative to the rate that would use it up exactly at the end of the window; a burn rate of 1 spends it all in exactly one window. Chapter 9
Business case: A structured argument for an investment that sets out the problem, the options (including doing nothing), their costs, benefits and risks, and a recommendation that decision makers can compare with other uses of the money. Chapter 11
Business drivers: The business goals, constraints and context that explain why a system exists and what success means, such as growth targets, regulation or contracts. In the ATAM they are presented first so that every finding can be traced to them. Chapter 11
Byte: A group of eight bits, able to hold 256 different values. Sizes of files and memory are counted in bytes (kilobytes, megabytes, gigabytes). Chapter 0
Bytecode: Compact instructions for a virtual machine rather than a real CPU. Java and Python compile source code to bytecode, which their runtimes then execute on any supported machine. Chapter 0

C

C4 model: Simon Brown's approach to architecture diagrams: a hierarchy of system context, container, component and code diagrams, plus a few supplementary diagrams. Chapter 4
Cache: A copy of data kept somewhere faster to reach, so repeated requests avoid slow work. It trades extra memory, and the risk of out-of-date data, for speed. Chapter 0
Cache hit ratio: The fraction of lookups that the cache can answer from its own contents; the rest are misses that go to the slower source. Chapter 7
Cache invalidation: Removing or marking stale a cached copy when the original data changes, so that later reads fetch the new value. Chapter 7
Cache stampede: A surge of requests that all miss the cache at the same moment, usually when a popular item expires, and all hit the slower source at once; closely related to the thundering herd problem. Chapter 7
Cache-aside: A caching pattern in which the application checks the cache, loads from the database on a miss and puts the result into the cache itself; also called lazy loading. Chapter 7
Canary release: Sending a small share of real traffic to a new version first, comparing its behaviour with the old version, and widening the share only if it is healthy. Chapter 10
Canonical data model: A single enterprise-wide representation of each business entity, into and out of which all messages are translated. Rarely fits every part of a business well. Chapter 6
CAP theorem: The result, conjectured by Eric Brewer in 2000 and proved by Gilbert and Lynch in 2002, that during a network partition a replicated system cannot be both linearisable and available to every request. Chapter 6
Capacity planning: Forecasting future demand, measuring how much each unit of infrastructure can handle and arranging enough capacity, with headroom, before it is needed. Chapter 9
Carbon-aware computing: Running software so that it does more when electricity is cleaner and less when it is dirtier, by shifting work in time or location or by shaping demand. Chapter 11
Cardinality: The number of distinct values a field can take; for metrics, the number of distinct label combinations, each of which becomes a separate time series to store. Chapter 9
Cascading failure: A failure that spreads: one slow or failed component makes its callers wait and exhaust their own resources, so they fail too, and so on up the chain. Chapter 6
Causal consistency: A consistency model in which operations that are causally related (one could have influenced the other) are seen in the same order by everyone; unrelated concurrent operations may be seen in different orders. Chapter 6
CBAM (Cost Benefit Analysis Method): An SEI method that builds on the ATAM by estimating the benefit of each architectural strategy from the utility it adds to prioritised scenarios, and dividing by its cost to compare value for cost. Chapter 11
Cell-based architecture: Running many complete, independent copies (cells) of a system, each serving a fixed subset of customers, behind a thin router, so that a failure affects only one cell. Chapter 10
Certificate authority (CA): An organisation or system that issues digital certificates by signing them, vouching that a public key belongs to a named server, person or workload. Chapter 8
Change coupling: Two or more files or components that tend to change in the same commits, revealing a dependency that may not be visible in the code. Chapter 1
Change data capture (CDC): Reading a database's own change or replication log to stream every committed insert, update and delete to other systems. Debezium is a widely used open-source CDC platform. Chapter 6
Chaos engineering: Experimenting on a system, ideally in production and under control, by injecting realistic failures to build confidence that it withstands turbulent conditions. Chapter 9
Chaos experiment: A controlled test that injects a real failure, such as killing an instance or slowing a dependency, to check a stated hypothesis about how the system keeps its steady state. Chapter 11
Characterisation test: A test that records what existing code actually does, rather than what it should do, so that changes can be checked against current behaviour. The term comes from Michael Feathers. Chapter 11
Chargeback: Charging each team's or product's budget for the costs attributed to it, so that the spending appears in its own accounts. Chapter 10
Choreography: Coordination of a multi-step process by participants reacting to each other's events, with no single component in charge. Chapter 6
Chunking: Splitting documents into passages small enough to index, retrieve and place in a prompt, ideally along the documents' own structure. Chapter 12
CI/CD pipeline: The automated sequence of steps (build, test, deploy to staging, deploy to production) that every change passes through on its way to users. Chapter 0
CIA triad: The three classic goals of information security: confidentiality (only authorised parties can read), integrity (no unauthorised changes) and availability (usable when needed). Chapter 2
Circuit breaker: A wrapper around calls to a dependency that, after enough failures, stops calling it for a while and fails fast, then lets trial calls through to test recovery (Michael Nygard, 2007). Chapter 9
Class and object: A class is a template that bundles data with the functions (methods) that work on it; an object is one instance made from that template, such as one customer's account. Chapter 0
Client-server model: An arrangement in which clients (such as browsers or mobile apps) send requests and servers, which hold shared data and logic, respond. Chapter 0
Closed layer: A layer that every request must pass through: the layer above may not skip it to call a lower layer directly. Chapter 5
Closed workload model: A load model with a fixed number of users, each sending a new request only after the previous one is answered (plus think time), so load falls when the system slows. Chapter 9
Cloud computing: Renting computing resources (servers, storage, databases and other services) over the internet, on demand, and paying for what you use. Chapter 0
Cloud native: An approach to building and running software as loosely coupled, automated, observable and resilient systems that are deployed programmatically and repeatably, in public, private or hybrid clouds. It describes how a system is built, not where it runs. Chapter 10
Cloud repatriation: Moving workloads out of a public cloud back to owned or colocated hardware, usually because steady load makes ownership cheaper. Chapter 10
Code review: Examination of a proposed code change by colleagues before it is merged, to find defects, share knowledge and keep the design consistent. Chapter 0
Cognitive bias: A systematic error in thinking, such as anchoring or the sunk cost fallacy, that leads people to judge options unfairly. Chapter 1
Cognitive load: The amount of mental effort a person or team must spend to understand and work within a system; Team Topologies uses it to size team responsibilities. Chapter 10
Cohesion: How closely the contents of one part of a system belong together. High cohesion means a module does one clear job. Chapter 0
Cold start: The extra delay when a serverless platform must create and initialise a new function instance before handling a request, from tens of milliseconds to several seconds. Chapter 6
Command: A message asking one specific handler to do something, such as AuthorisePayment. Unlike an event, it can be refused. Chapter 6
Command-query separation (CQS): Bertrand Meyer's principle that a method should either change state (a command) or return an answer (a query), but not both. Chapter 7
Commit: A saved snapshot of changes in version control, with an author, a timestamp and a message explaining the change. Chapter 0
Commitment discount: A lower price in exchange for committing to a level of usage or spend for one or three years, such as reserved instances, savings plans or committed use discounts. Chapter 10
Common closure principle (CCP): Classes that change for the same reasons and at the same times belong in the same component; the single responsibility principle applied to components. Chapter 3
Common reuse principle (CRP): Classes that are used together belong together, and users of a component should not be forced to depend on classes they do not use. Chapter 3
Communication paths: The possible one-to-one links between members of a group. A group of n people has n(n-1)/2 of them, so the number grows roughly with the square of the group size. Chapter 3
Compensating transaction: A new transaction that semantically counteracts the effect of an earlier, already committed one, such as voiding a card authorisation. Unlike a rollback, the original may already have been seen. Chapter 6
Competing consumers: A pattern in which several workers read from the same queue and each message is processed by only one of them, so throughput grows by adding workers. Chapter 9
Compiler: A program that translates source code into another form, such as machine code or bytecode, before the program runs. Chapter 0
Complicated-subsystem team: A team that owns a part of the system needing scarce specialist knowledge, such as an optimisation algorithm or video codec, so that stream-aligned teams can use it without mastering it. Chapter 11
Component: A unit that exists when the system runs, such as a service, a process or a database, which interacts with other components through connectors. Chapter 1
Component (C4): In the C4 model, a group of related functionality behind a clear interface, running inside a container and deployed with it. Chapter 4
Component-and-connector view: A view of what exists at runtime, such as services, clients, databases and queues, and the connectors (calls, messages, shared data) between them. Chapter 4
Composition root: The single place, usually the program's start-up code, where concrete adapters are created and plugged into the application. Chapter 5
Concern: An interest a stakeholder has in a system, such as its cost, performance, security, ease of change or legal compliance. Chapter 1
Concrete scenario: A scenario written for one particular system, with specific actors, events, conditions and numbers, ready to be designed for and tested. Chapter 2
Configuration drift: Differences that build up between the intended configuration in code and the real infrastructure, usually from manual changes or partial updates. Chapter 10
Configuration management: Tools such as Ansible, Chef and Puppet that bring existing, long-lived servers into a described configuration by installing packages and editing files on them. Chapter 10
Confused deputy: A program that holds authority and is tricked into using it on behalf of someone who lacks that authority (Norm Hardy, 1988). Chapter 12
Connascence: Two elements are connascent if a change to one would require a change to the other for the system to stay correct. A finer-grained way of describing coupling, introduced by Meilir Page-Jones. Chapter 3
Connection draining: Stopping new requests to an instance that is being removed while letting the requests already in progress finish, so that scaling in and deployments drop no work. Chapter 9
Connector: The runtime mechanism by which components interact: an HTTP call, a message queue, a shared database, an event stream or a function call. Chapter 1
Consensus: A decision rule in which the group continues until everyone actively agrees, or at least supports, the proposal; inclusive but slow, and prone to stalemate in large groups. Chapter 11
Consent decision-making: A decision rule in which a proposal is adopted unless someone raises a reasoned objection that it would cause harm or move the group backwards; it asks whether people can live with a proposal, not whether they prefer it. Chapter 11
Consistency model: The contract a data store offers about which values reads may return given the writes that have happened, and therefore which stale or reordered results clients must be prepared for. Chapter 6
Consistent hashing: A way of assigning keys to nodes on a hash ring so that adding or removing a node moves only about 1/N of the keys (Karger and colleagues, 1997). Chapter 7
Constraint: A design decision that has already been made for you, with zero or very little freedom left, such as a required programming language, a regulation, a fixed deadline or a budget. Chapter 2
Consumer group: A set of consumers that share the work of reading a topic: each partition is read by one member, and each group keeps its own offsets. Chapter 6
Consumer-driven contract: A contract assembled from what each consumer actually uses of a provider's API; the provider runs all its consumers' expectations in its own build so it knows which changes would break whom. Chapter 6
Container: A packaged application with its libraries and settings, run as an isolated process that shares the host's operating-system kernel. Lighter and faster to start than a virtual machine. Chapter 0
Container (C4): In the C4 model, a separately runnable or deployable unit that runs code or stores data, such as a web app, mobile app, service or database. It is not a Docker container. Chapter 4
Container diagram: A C4 diagram showing the apps, services and data stores inside one system, with their technologies and how they communicate. Chapter 4
Container image: A read-only, versioned package containing an application and everything it needs to run, from which identical containers can be started anywhere. Chapter 0
Container orchestration: Automatically scheduling containers onto machines and keeping them running: restarting failures, scaling, rolling out new versions, and connecting them to networks and storage. Chapter 10
Containers as a service (CaaS): A cloud service that runs container images for you, either as managed Kubernetes or as a serverless container platform where you never see the machines. Chapter 10
Content delivery network (CDN): A network of servers in many locations that keeps copies of content such as images, scripts and video close to users, so that it loads faster and the origin server does less work. Chapter 0
Context map: A picture of a system's bounded contexts and the relationships between them, such as customer-supplier or anticorruption layer, covering both integration and team relationships. Chapter 5
Context propagation: Passing trace identifiers (and other request context) from one service to the next with each call or message, for example in the W3C traceparent header. Chapter 9
Context window: The maximum number of tokens a model can take into account in one call, including instructions, history, supplied documents and its own answer. Chapter 12
Continual fitness function: A fitness function that runs all the time against the live system, such as SLO monitoring or synthetic transactions, rather than being triggered by a build or event. Chapter 11
Continuous delivery: Keeping software always in a releasable state, so that any version that passes the automated pipeline can be put into production at the press of a button. Chapter 0
Continuous deployment: Automatically releasing every change that passes the pipeline to production, with no manual approval step. Chapter 0
Continuous integration (CI): The practice of merging every developer's changes into the shared main line frequently, at least daily, with an automated build and tests verifying each change. Chapter 0
Contract testing: Testing each side of an integration in isolation against a shared description of their interactions, instead of deploying both together for end-to-end tests. Chapter 6
Contributing factor: One of the several conditions that together made an incident possible or worse; reviews look for many contributing factors rather than a single root cause. Chapter 9
Control plane: The components that make decisions for a cluster or system (in Kubernetes: the API server, etcd, scheduler and controllers), as opposed to the nodes that run the workloads. Chapter 10
Controller: The organisation that decides why and how personal data is processed and carries primary responsibility for complying with data protection law. Chapter 8
Conway's law: Melvin Conway's 1968 observation that organisations design systems whose structure mirrors the organisation's own communication structure. Chapter 1
Cooldown (stabilisation window): A period after a scaling action during which the autoscaler waits before acting again, so that the effect of the last change can be measured. Chapter 9
Coordinated omission: A measurement error, named by Gil Tene, in which a load generator waits for slow responses before sending more requests and so never records the delays real users would have suffered. Chapter 9
Core domain: The subdomain that gives the business its competitive advantage and therefore deserves the best people, the richest modelling and code the company owns. Chapter 5
Core system: In a microkernel architecture, the minimal part of the application that every installation needs: the main workflow, shared services and the points where plug-ins attach. Chapter 5
Correspondence: A recorded relation between elements of an architecture description, for example between a container in one view and the server it runs on in another. Chapter 4
Cost of change: The effort, money, time and risk needed to alter a decision once work has been built on top of it. Chapter 1
Cost of delay: The value lost for each unit of time a piece of work is not delivered; Don Reinertsen popularised it as a way to prioritise work economically. Chapter 11
Counter: A metric whose value only goes up (or resets to zero on restart), such as total requests served; you usually look at its rate of increase. Chapter 9
Coupling: How much one part of a system depends on the details of another. Loose coupling means a change in one part rarely forces changes elsewhere. Chapter 0
CPU (processor): The central processing unit: the chip that carries out a program's instructions, one simple step at a time, billions of times a second. Modern CPUs have several cores that work in parallel. Chapter 0
CQRS: Command query responsibility segregation: using separate models, and often separate stores, for updating data and for reading it. Chapter 6
Cross-cutting concept: A rule or solution that applies across many parts of a system, such as security, error handling, logging or persistence. Chapter 4
Cross-cutting concern: A concern that affects many parts of a system at once, such as logging, security, error handling or persistence, and so is usually decided once for the whole system. Chapter 1
Crypto-shredding: Making data unreadable by destroying the encryption key that protects it, used to erase personal data from logs and backups that cannot be edited. Chapter 7
Cursor pagination: Paging through a collection by passing an opaque token that marks the last item seen, rather than a numeric offset. It stays fast and stable when items are added during paging. Chapter 6
CVE: Common Vulnerabilities and Exposures: the programme that gives each publicly known vulnerability a unique identifier such as CVE-2021-44228. Chapter 8
CVSS: The Common Vulnerability Scoring System, maintained by FIRST, which rates the severity of a known vulnerability from 0 to 10; version 4.0 was published in 2023. Chapter 8
Cyber Resilience Act (CRA): Regulation (EU) 2024/2847, which sets cybersecurity requirements, vulnerability handling and reporting duties for hardware and software products sold in the EU. Chapter 8
Cyclomatic complexity: Thomas McCabe's 1976 measure of the number of independent paths through a piece of code, computed from its control-flow graph; for simple code it equals the number of decisions plus one. Chapter 3

D

Dark launching: Calling new back-end behaviour in production with real traffic while hiding its results from users, to test performance and correctness before a visible release. Chapter 11
Dark pattern: A user interface designed to trick or pressure people into choices they would not otherwise make, such as hidden costs or hard-to-cancel subscriptions; Harry Brignull coined the term in 2010 and now calls them deceptive patterns. Chapter 11
Data centre: A building designed to house many servers with reliable power, cooling, physical security and network connections. Chapter 0
Data collision: In a replicated in-memory cache, two units updating the same item before replication has propagated the first update, so one update overwrites the other. Chapter 6
Data contract: An explicit, versioned agreement between a data owner and its consumers covering schema, meaning, quality, freshness, ownership and how changes are announced. Chapter 7
Data egress: Data leaving a cloud provider's network, or crossing between its zones or regions, which is usually charged per gigabyte. Chapter 10
Data lake: A large, cheap store, usually object storage, that keeps raw data from many sources in its original form for later analysis. Chapter 7
Data lineage: A record of where a piece of data came from and every transformation it went through on the way. Chapter 7
Data mesh: Zhamak Dehghani's approach to analytical data in which domain teams own and publish their data as products on a self-serve platform under federated governance. Chapter 7
Data ownership: The rule that each piece of data is written by exactly one module or service, which others must ask rather than reading or changing its storage directly. Chapter 3
Data product: A dataset published by a domain team for others to use, with an owner, documentation, quality guarantees and a stable interface. Chapter 7
Data protection by design and by default: The GDPR Article 25 duty to build data protection principles into systems through appropriate measures, and to process only the data necessary for each purpose by default. Chapter 8
Data protection impact assessment (DPIA): An assessment required by GDPR Article 35 before processing likely to result in a high risk to people, describing the processing, its necessity, the risks and the measures that address them. Chapter 8
Data provenance: The documented origin and history of data: where it came from, under what licence or consent, and how it has been transformed. Chapter 12
Data residency: A requirement that certain data be stored, and sometimes processed, only in a particular country or region. Chapter 2
Data structure: A way of organising data in memory, such as a list, dictionary, set, queue, stack, tree or graph, chosen to make the operations you need fast. Chapter 0
Data type: The kind of value a piece of data is, such as an integer, a decimal number, text or true/false, which decides what operations make sense on it. Chapter 0
Data warehouse: A database built for analysis that integrates cleaned data from many operational systems and keeps its history. Chapter 7
Data-flow diagram (DFD): A diagram of external entities, processes, data stores and the data flows between them, with trust boundaries drawn across the flows; the usual model for threat modelling. Chapter 8
Database: An organised collection of data stored so that it can be searched, updated and kept consistent, usually managed by a database management system. Chapter 0
Database index: An extra data structure, usually a B-tree, that lets the database find rows by a column's value without reading the whole table. It speeds up reads but slows writes and uses space. Chapter 0
Database management system (DBMS): The software that stores a database and controls access to it: it answers queries, enforces rules, handles many users at once and recovers after crashes. PostgreSQL and MySQL are examples. Chapter 0
Database per service: The rule that each service owns its data and no other service reads or writes it directly; others use the owner's API or its events. Chapter 6
Dead code: Code that is no longer meant to run but is still present in the deployed system, where it can be triggered by mistake. Chapter 1
Dead-letter queue: A separate place where messages that repeatedly fail processing are parked for inspection, so they do not block the rest of the flow. Chapter 5
Deadline propagation: Passing the time remaining for a whole request to every downstream call, so that no service keeps working on a request its caller has already abandoned. Chapter 9
Decision driver: A force or criterion, such as a quality goal or constraint, that an architectural decision must satisfy and against which options are compared. Chapter 4
Decision log: The ordered collection of a system's ADRs, usually with an index listing each record's number, title, status and date. Chapter 4
Decision rights: An explicit statement of who may make which decisions, who must be consulted and who must be informed; settling them before a debate prevents most disputes about process. Chapter 11
Decomposition: Splitting a system into parts (modules) and deciding what each part is responsible for. The criterion used to split matters more than the number of parts. Chapter 3
Deep module: John Ousterhout's term for a module whose simple interface hides a large amount of functionality. A shallow module offers little behaviour for the complexity of its interface. Chapter 3
Defence in depth: Layering several independent controls so that an attacker who defeats one still faces others, for example a gateway check, a service check and encryption of the data itself. Chapter 8
Degree (of connascence): How many elements share a particular connascence. A value agreed by two functions is far easier to change than one agreed by forty services. Chapter 3
Dependency: Any piece of software that your code needs in order to work, such as a library, a framework or another service. If it changes or breaks, your code may break too. Chapter 0
Dependency cycle: A loop in which modules depend on each other directly or indirectly, so none can be understood, tested or released alone. Chapter 1
Dependency injection: Giving a component the collaborators it needs (a database, a clock, a payment gateway) from outside instead of letting it create them, so they can be swapped, for example for fakes in tests. Chapter 2
Dependency inversion: Making a high-level module and a low-level module both depend on an abstraction, usually owned by the high-level side, so that the source-code dependency points against the flow of control. Chapter 3
Dependency inversion principle (DIP): High-level policy should not depend on low-level details; both should depend on abstractions, and the abstraction should be owned by the policy side. Chapter 3
Dependency rule: Robert C. Martin's rule for clean architecture: source code dependencies point only inwards, so inner rings never name anything declared in outer rings. Chapter 5
Deployability: How quickly, safely and predictably a change can be put into production, and taken back out again if needed. Chapter 2
Deployment (Kubernetes): A Kubernetes object that declares how many identical pods of a stateless application should run and rolls out new versions gradually through ReplicaSets. Chapter 10
Deployment coupling: A situation in which two parts must be released together, or in a fixed order, because a change in one breaks the other. Chapter 3
Deployment diagram: A diagram (in C4 or UML) showing how software is mapped onto infrastructure in one environment, including nodes, replicas and network paths. Chapter 4
Deployment pipeline: The automated sequence of stages (build, tests, packaging, deployment, verification) that every change passes through on its way from a commit to production. Chapter 10
Deployment unit: The thing that is built, released and started as one piece: one executable, one container image or one web archive, for example. Chapter 5
Design by contract: Bertrand Meyer's method of specifying each operation with preconditions the caller must meet, postconditions the operation guarantees, and invariants that always hold. Chapter 3
Design document (RFC): A written proposal for a significant change, covering problem, goals, design and alternatives, circulated for comment before the change is built. Chapter 4
Design pattern: A reusable solution to a recurring problem at the scale of a few classes or objects, such as Strategy or Observer; smaller in scope than an architectural pattern. Chapter 5
Design review (RFC review): A written review of a proposed design document or request for comments, in which affected people comment asynchronously before the design is approved and its decisions recorded. Chapter 11
Desired state: A declarative description of what a system should look like (for example, three copies of version 2.4), which automation compares with the actual state and works to achieve. Chapter 10
Detailed design: Decisions about the inside of one part of a system (its classes, functions, algorithms and local data structures) that can be changed without affecting the rest. Chapter 1
Developer portal: A web interface, such as Backstage, that gathers a software catalogue, templates, documentation and links to platform services in one place. Chapter 10
DevOps: A culture and set of practices in which development and operations work as one, sharing responsibility for building, releasing and running software, supported by automation and measurement. Chapter 0
Diagrams as code: Writing diagrams as text in a small language, such as PlantUML, Mermaid, D2 or Structurizr DSL, which a tool lays out and draws. Chapter 4
Dictionary (map): A data structure that stores values under unique keys, so a value can be found directly by its key, usually in roughly constant time. Also called a map or hash table. Chapter 0
Dimension table: A table of descriptive attributes, such as a restaurant's name, cuisine and city, used to filter and group facts. Chapter 7
Disagree and commit: A norm in which people state their disagreement openly before a decision and then commit fully to carrying it out once it is made. Chapter 11
Disaster recovery (DR): The plans, copies and procedures that restore a service and its data after a large failure, such as the loss of a whole data centre or region. Chapter 10
Discount rate: The annual rate used to convert future money into today's value, reflecting the cost of capital and risk; usually set by the finance department. Chapter 11
Disposability: The property of processes that start quickly, shut down gracefully and can be killed at any time without harm, so they can be replaced and scaled freely. Chapter 10
Distributed architecture: An architecture made of several separately deployed units that cooperate by sending messages over a network. Chapter 5
Distributed monolith: A system deployed as separate services that are so tightly coupled they must be changed and released together, giving the costs of distribution without its benefits. Chapter 5
Distributed SQL (NewSQL): Relational databases such as Spanner and CockroachDB that keep SQL and ACID transactions while partitioning and replicating data across many nodes or regions. Chapter 7
Distributed system: A set of programs running on different computers that cooperate by sending messages over a network so that users see one service. Chapter 6
Distributed tracing: Recording the path and timing of one request as it travels through many services, so that the slow or failing step can be found. Chapter 9
DNS: Domain Name System: the internet's directory service, which turns names such as www.example.com into IP addresses. Chapter 0
Docker: A widely used set of tools, released in 2013, for building container images and running containers. Its image format became an open standard. Chapter 0
Docs as code: Producing documentation with the same tools and workflow as software: plain-text files in version control, code review, automated checks and publishing. Chapter 4
Document database: A NoSQL database that stores each record as a self-contained document, usually JSON-like, which can hold nested data and need not share a fixed schema. Chapter 0
Domain event: A record of something meaningful that happened in the business domain, named in the past tense, such as OrderPlaced or CourierAssigned. Chapter 5
Domain model: A small diagram or description of the key business concepts of a system, their attributes and how they relate, shared by developers and domain experts. Chapter 4
Domain partitioning: Dividing a system's top-level structure by business capability or subdomain, such as ordering, payments and delivery. Chapter 5
Domain service: In service-based architecture, a separately deployed service that covers a whole business area, such as ordering or payments, from API to data access. Chapter 6
Domain-driven design (DDD): An approach introduced by Eric Evans in 2003 that builds software around a model of the business domain, developed with domain experts, and divides large domains into explicitly bounded models. Chapter 5
DORA metrics: The software delivery performance measures from the DORA research programme: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Chapter 2
Drawing tool: A diagramming tool that knows only shapes, lines and text, so the same element drawn in two diagrams has no link between them. Chapter 4
Drift: A gradual change in an AI system's inputs, knowledge sources, the world or the model itself that makes its outputs less accurate over time without any code change. Chapter 12
Driven (secondary) adapter: An adapter that implements an interface the application calls when it needs something from outside, such as storing data, charging a card or sending a message. Chapter 5
Driving (primary) adapter: An adapter that receives requests from outside, such as a web controller, a test harness or a scheduled job, and calls the application through a driving port. Chapter 5
DRY: Don't repeat yourself: the principle from The Pragmatic Programmer that every piece of knowledge should have one authoritative representation in a system. It is about knowledge, not identical-looking text. Chapter 3
Dual write: Updating two systems, such as a database and a message broker, in separate operations; a crash between them leaves the two inconsistent. Chapter 6
Dynamic connascence: Connascence that only shows when the program runs, such as dependence on the order or timing of execution, on related values or on two parts sharing the same object instance. Chapter 3
Dynamic diagram: A supplementary C4 diagram showing how elements collaborate at runtime in one scenario, usually as numbered interactions. Chapter 4

E

Edge function: A small piece of code run by a CDN or edge provider in locations close to users, to handle or change requests before (or instead of) reaching the origin. Chapter 10
Efferent coupling (Ce): The number of things outside a component that it depends on: its outgoing dependencies. High Ce means it is exposed to many others' changes. Chapter 3
Elasticity: The ability to add and remove resources automatically as load rises and falls, so capacity follows demand and you pay only for what you use. Chapter 2
Element: A part of a system that an architect reasons about as a unit, such as a module, a service, a database, a queue or a server. Chapter 1
Elicitation: Actively drawing requirements out of stakeholders, documents, regulations and existing systems, rather than waiting for them to be stated. Chapter 2
Embedding: A vector of numbers representing the meaning of text, an image or an item, arranged so that similar meanings are close together. Chapter 12
Embodied carbon: The greenhouse gas emitted in making, transporting and disposing of hardware, as opposed to the emissions from the electricity it uses while running. Chapter 11
Emergent design: An approach in which the design grows incrementally, shaped by the needs of each new piece of functionality and continuous refactoring. Chapter 1
Enabling team: A team of specialists that helps other teams acquire a missing capability, such as test automation or observability, for a limited period and then moves on, rather than doing the work for them. Chapter 11
Encapsulation: Keeping an object's or module's internal data and details private, so other code can use it only through the operations it chooses to offer. Chapter 0
End-to-end test: An automated test that drives the whole system as a user would, for example by tapping through an app, to check a complete journey. Chapter 0
Enterprise architecture: Architecture at the level of a whole organisation: how its business capabilities, information, applications and technology fit together and change over time. Chapter 1
Enterprise service bus (ESB): Middleware at the centre of classic SOA that routes, transforms and mediates messages between services and often runs business processes as well. Chapter 6
Entity: A domain object defined by an identity that persists over time while its attributes change, such as an order or a customer. Chapter 5
Entity of interest: In ISO/IEC/IEEE 42010:2022, the thing whose architecture is being described: a software system, a system of systems, a product line or an enterprise. Chapter 4
Entry point (Python packaging): Metadata in an installed Python package that advertises an object, such as a plug-in class, under a named group so that other code can discover it at run time. Chapter 5
Envelope encryption: Encrypting data with a data key and then encrypting (wrapping) that data key with a key-encryption key held in a KMS, so bulk data never travels to the KMS and keys can be rotated cheaply. Chapter 8
Environment: A separate, complete copy of the system and its settings used for one purpose, such as development, testing, staging or production. Chapter 0
EPSS: The Exploit Prediction Scoring System from FIRST, which estimates the probability that a vulnerability will be exploited in the next 30 days. Chapter 8
Error: Part of a system's internal state that is wrong because a fault has been activated, such as a corrupted record. An error may or may not lead to a failure. Chapter 2
Error budget: The amount of unreliability an SLO allows: one minus the target, applied to the window. A 99.9% SLO over 1,000,000 requests allows 1,000 bad requests. Chapter 9
Error budget policy: An agreed, written statement of what a team will do when its error budget is being spent too fast or is exhausted, such as freezing risky releases. Chapter 9
Essential complexity: Complexity that belongs to the problem itself, such as the real rules of tax or insurance, and cannot be removed without changing what the system does. Chapter 3
ETag: An HTTP response header carrying an identifier for one version of a resource, which a client can send back in If-None-Match to ask whether it has changed. Chapter 7
ETL: Extract, transform, load: a pipeline that takes data from source systems, cleans and reshapes it, and loads it into a target store such as a data warehouse. Chapter 5
EU AI Act: Regulation (EU) 2024/1689, the European Union's risk-based law on artificial intelligence, amended in 2026 by Regulation (EU) 2026/1744. Chapter 12
Eval (evaluation): A repeatable experiment that runs a fixed set of inputs through an AI system and scores the outputs, producing numbers that can be compared between versions. Chapter 12
Event: An immutable record of something that has happened, named in the past tense, such as OrderPlaced. Any number of receivers may react to it. Chapter 6
Event interception: A legacy displacement pattern that catches state-changing requests or events on their way into a legacy system and forwards some of them to a new component as well, or instead. Chapter 11
Event notification: An event that only signals a change, often carrying just an identifier, so receivers that need details must ask the publisher. Chapter 6
Event sourcing: Storing every change to an entity as an event, so the event log is the source of truth and current state is derived by replaying it. Chapter 6
Event storming: A workshop format created by Alberto Brandolini in which domain experts and developers place domain events on a timeline to explore a business process and find boundaries. Chapter 5
Event stream: The ordered sequence of events for one aggregate, numbered by version, from which that aggregate's state is rebuilt. Chapter 7
Event time: The time at which an event actually happened, as opposed to processing time, when a system observes it. Chapter 7
Event-carried state transfer: Events that carry enough data for receivers to keep their own copy, so they need not call the publisher. Chapter 6
Event-driven architecture: A style in which components communicate by publishing events about things that have happened and reacting to events published by others, usually through a broker. Chapter 6
Eventual consistency: A guarantee that copies of data that have stopped being updated will converge to the same value after some time, while readers may see stale values in between. Chapter 6
Evolutionary architecture: An architecture that supports guided, incremental change across multiple dimensions, with fitness functions providing the guidance (Ford, Parsons, Kua and Sadalage). Chapter 11
Excessive agency: Giving an AI system more tools, permissions or autonomy than its task needs, so that a manipulated or mistaken model can do real damage. Chapter 12
Exit strategy: A documented and ideally rehearsed plan for leaving a provider or product, covering data export, replacement services, contracts, time and cost. Chapter 10
Expand and contract: Making a breaking change in safe steps: add the new structure alongside the old, migrate readers, writers and data, then remove the old structure. Also called parallel change. Chapter 7
Exponential backoff: Waiting longer between successive retries, typically doubling the delay each time up to a cap, so that a struggling service gets time to recover. Chapter 9
Extension point: A named slot that a host application or plug-in declares so that other plug-ins can contribute behaviour to it, as in the Eclipse platform. Chapter 5

F

Fact table: The central table of a star schema, holding one row per business event at a stated grain, with numeric measures and keys to dimensions. Chapter 7
Failover: Switching work from a failed component to a healthy standby or replica, automatically or by hand. Chapter 2
Failure: An event in which the service a system delivers deviates from what it should be, in a way its users can observe. Chapter 2
Faithfulness: In RAG evaluation, the degree to which every claim in an answer is supported by the retrieved passages; also called groundedness. Chapter 12
Fallacies of distributed computing: Eight false assumptions about networks listed at Sun Microsystems by L Peter Deutsch and colleagues, with James Gosling adding the eighth: for example that the network is reliable and that latency is zero. Chapter 6
Fallback ladder: An ordered list of alternatives (other regions, providers, models, then a non-AI response) tried in turn when the preferred model fails or is unavailable. Chapter 12
Fan-out: A pattern in which one incoming request triggers several parallel requests to other services or servers, whose answers are then combined. Chapter 2
Fault: The cause of a problem, such as a bug, a failed disk or a misconfiguration. A fault may lie dormant until something activates it. Chapter 2
Fault tolerance: The ability of a system to keep delivering its service even though one of its parts has failed, usually through redundancy. Chapter 2
Feature flag: A configuration switch that turns a piece of behaviour on or off at run time without deploying new code. Chapter 1
File: A named sequence of bytes stored on a disk and managed by the operating system, such as a photo, a spreadsheet or a log. Chapter 0
Filter: A self-contained processing step that reads input, then produces, transforms, tests or consumes it, without knowing which steps come before or after it. Chapter 5
Fine-tuning: Further training of an existing model on a smaller, targeted data set to teach it a task, format, tone or vocabulary. Chapter 12
FinOps: A practice in which engineering, finance and business teams share responsibility for cloud and technology spending, using timely cost data to make decisions that maximise business value. Chapter 10
Fitness function: An automated check that tells you whether a system still has an architectural property, such as a test that fails when one module depends on another it must not use. Chapter 1
Flapping: An autoscaler repeatedly adding and removing capacity because it reacts to short-lived changes or to the effects of its own actions. Chapter 9
Follow one request: Explaining a system by tracing a single concrete event, such as one order, step by step through every part it touches. Chapter 4
Foreign key: A column in one table that holds the primary key of a row in another table, linking the two. The database can refuse values that point to nothing. Chapter 0
Forward compatibility: A schema change is forward compatible when code using the old schema can still read data written with the new one, usually by ignoring fields it does not know. Chapter 7
Four golden signals: Latency, traffic, errors and saturation: the four measurements the Google SRE book recommends monitoring for any user-facing system. Chapter 9
Fracture plane: A natural seam along which a software system can be split so that each part suits one team, for example a bounded context, a regulatory boundary, a different change cadence or a different risk profile. Chapter 11
Framework: Reusable code that provides the overall structure of an application and calls your code at the right moments, such as Django or Spring. Chapter 0
Function: A named, reusable piece of code that takes inputs (parameters), does some work and usually returns an output. Chapter 0
Functional requirement: A statement of what a system must do: a behaviour, calculation or piece of information it must provide, such as 'a customer can cancel an order before it is dispatched'. Chapter 2
FURPS+: A quality classification that originated at Hewlett-Packard as FURPS (functionality, usability, reliability, performance and supportability), later extended with '+' for constraints such as design, implementation, interface and physical limits. Chapter 2

G

Game day: A planned exercise in which a team deliberately causes or simulates a failure and practises detecting, responding to and recovering from it. Chapter 9
Gate (governance): A checkpoint at which work stops until someone approves it, such as a review-board sign-off before build or release. Chapter 11
Gateway API: The Kubernetes API for routing external and internal traffic into services, generally available since 2023 and the recommended successor to Ingress. Chapter 10
Gauge: A metric that records a current value that can go up or down, such as queue length, memory in use or temperature. Chapter 9
General scenario: A system-independent template listing the typical sources, stimuli, environments, responses and measures for one quality attribute. Chapter 2
General-purpose AI model: Under the EU AI Act, an AI model, such as a large language model, that can perform a wide range of tasks and be integrated into many downstream systems. Chapter 12
Generic subdomain: A subdomain whose problems many businesses share and for which good solutions exist, such as payments or identity; usually bought or built thinly. Chapter 5
Git: The most widely used version control system, created by Linus Torvalds in 2005. Every developer has a full copy of the project's history. Chapter 0
GitOps: Operating systems by keeping their declarative desired state in Git and letting agents pull it and continuously reconcile the running system to match it. Chapter 10
Global load balancing: Distributing users across data centres or regions, usually by DNS answers that differ by location and health, or by anycast routing. Chapter 9
Golden path (paved road): An opinionated, supported and documented way to do a common task, such as creating a new service, that is the easiest way but not the only permitted way. Chapter 10
Golden set: A curated, versioned collection of test inputs with the expected outcome, reference answer or scoring rubric for each, used to evaluate an AI system. Chapter 12
Goodhart's law: The observation, often phrased as 'when a measure becomes a target, it ceases to be a good measure', that people optimise the number rather than the thing it was meant to indicate. Chapter 3
Graceful degradation: Continuing to provide the most important functions when part of a system fails, instead of failing completely, for example a shop that still takes orders while recommendations are offline. Chapter 2
Granularity: The size of modules or services relative to the whole system. Coarse-grained means few large parts; fine-grained means many small ones. Each has costs. Chapter 3
Graph database: A database that stores items as nodes and the relationships between them as edges, so that following chains of connections is fast. Chapter 0
GraphQL: A query language and runtime for APIs, released by Facebook in 2015, in which the client sends a query naming exactly the fields it wants from a typed schema and receives a response of the same shape. Chapter 6
gRPC: A remote procedure call framework, open-sourced by Google in 2015, that sends Protocol Buffers messages over HTTP/2 and generates typed client and server code. It supports streaming in either or both directions. Chapter 6
Guard: A condition in square brackets on a transition or flow that must be true for it to be taken, such as [code matches]. Chapter 4
Guardrail: An automatic limit or check that keeps self-service use safe (for example, a policy that blocks public storage buckets) without requiring a person to approve each request. Chapter 10

H

Hallucination: Model output that is fluent and confident but false or unsupported by its sources, such as an invented citation or policy. Chapter 12
Hardware: The physical parts of a computer that you could touch: the processor, memory, storage, network card, screen and so on. Chapter 0
Hardware security module (HSM): Tamper-resistant hardware that generates and uses keys inside itself and never releases them in plaintext; KMS services are usually built on HSMs. Chapter 8
Headroom: Spare capacity kept deliberately above expected peak load, to absorb bursts, failures and the time it takes to add more capacity. Chapter 9
Health check: A periodic test, such as an HTTP request to a status endpoint, that a load balancer or orchestrator uses to decide whether an instance should receive traffic or be restarted. Chapter 9
Heartbeat: A periodic "I am alive" message sent by a component; if the messages stop, a monitor assumes the component has failed and acts. Chapter 2
Hedged request: Sending a second copy of a slow request to another replica after a short delay and using whichever answer arrives first, to cut tail latency. Chapter 9
High-risk AI system: Under the EU AI Act, an AI system that is a safety component of a regulated product (Annex I) or used in a sensitive area listed in Annex III, such as employment or credit. Chapter 12
Histogram: A metric that counts observations into value ranges called buckets, such as request durations, so that percentiles can be estimated and histograms from many servers can be added together. Chapter 9
HNSW: Hierarchical navigable small world graphs (Malkov and Yashunin, 2016): a widely used index for approximate nearest-neighbour search over vectors. Chapter 12
Holistic fitness function: A fitness function that checks several characteristics together in a shared context, such as a load test that measures latency while security and logging are switched on. Chapter 11
Horizontal Pod Autoscaler (HPA): A Kubernetes controller that changes the number of pod replicas to keep a metric, such as average CPU use relative to requests, near a target. Chapter 10
Hotspot: A part of the code that is both complex and frequently changed, found by combining version-control history with a complexity measure; a likely place to repay debt. Chapter 1
HTTP: Hypertext Transfer Protocol: the request-and-response language of the web, in which a client sends a method such as GET to a URL and a server replies with a status code and content. Chapter 0
HTTP status code: A three-digit number in every HTTP response saying how the request went: 2xx success, 3xx redirection, 4xx a problem with the request, 5xx a problem on the server. Chapter 0
Human in the loop: A design in which a person reviews, approves or corrects a model's output before or after it takes effect. Chapter 12
Human oversight: Arrangements that let people monitor, approve, override or stop an AI system's decisions. Chapter 12
Hybrid cloud: A combination of private and public cloud (or on-premises systems) connected so that data and applications can work across them. Chapter 10
Hybrid search: Retrieval that combines keyword (sparse) and embedding (dense) results, usually by merging their rankings, to get the strengths of both. Chapter 12
Hypermedia controls (HATEOAS): Links in an API response that tell the client which actions it can take next, so the client follows links rather than building URLs itself. Level 3 of the Richardson maturity model. Chapter 6
Hypervisor: Software that creates and runs virtual machines, sharing one physical computer's processors, memory and devices among them while keeping them isolated. Chapter 0
Hyrum's law: The observation, named after Hyrum Wright, that with enough users of an API every observable behaviour will be depended on by somebody, whatever the contract promises. Chapter 3

I

IaaS (infrastructure as a service): A cloud model in which you rent virtual machines, storage and networks, and manage the operating system and everything above it yourself. Chapter 0
Idempotency: The property of an operation that has the same effect whether it is performed once or several times, which makes retries safe. Usually achieved with a unique request or event identifier that the receiver remembers. Chapter 6
Idempotency key: A unique value a client sends with a non-idempotent request, such as POST, so that the server can recognise a retry of the same operation and return the original result instead of doing the work twice. Chapter 6
Idempotent: Describes an operation that has the same effect whether it is applied once or several times, so it can be retried safely. Chapter 5
Idempotent consumer: A message receiver that records which messages it has processed, in the same transaction as their effects, so that duplicates change nothing. Chapter 6
Immutable backup: A backup copy that cannot be changed or deleted before its retention period ends, even by an administrator, protecting it from ransomware and malicious insiders. Chapter 8
Immutable infrastructure: The practice of never changing a running server or container in place; every change is made by building a new image and replacing the old instances. Chapter 10
Implicit requirement: A quality that every stakeholder assumes but nobody writes down, such as 'orders are never lost' or 'the system keeps working across a clock change'. Chapter 2
In-memory data grid: Software that holds data in the memory of many machines as one logical store, with partitioning and replication, for very fast access. Hazelcast, Apache Ignite and Oracle Coherence are examples. Chapter 6
In-process event: A message published inside one running application so that other modules can react to something that happened, without the publisher knowing who listens. Chapter 5
Incident commander: The person who coordinates the response to an incident: sets priorities, assigns roles and makes decisions, rather than fixing things personally. Chapter 9
Incident response: The organised handling of a security incident: detecting and analysing it, containing it, removing the cause, recovering and learning from it. Chapter 8
Independent deployability: The ability to change and release one service to production without changing, testing or releasing any other service at the same time. Chapter 6
Index: An extra data structure, kept alongside data, that lets a system find items by a chosen field without scanning everything, like the index at the back of a book. Chapter 0
Indirect prompt injection: Prompt injection delivered through content the system reads, such as a web page, email, document or tool result, rather than typed by the user. Chapter 12
Inference: Using a trained model to produce outputs for new inputs. In production it is a service with latency, throughput and per-call cost, unlike training, which is a heavy batch job. Chapter 12
Information hiding: David Parnas's principle (1972) that each module should hide a design decision that is difficult or likely to change, so that the decision can change without affecting other modules. Chapter 3
Infrastructure as code (IaC): Defining servers, networks, databases and other infrastructure in version-controlled files that tools apply automatically, instead of configuring them by hand. Chapter 10
Instability (I): Martin's metric I = Ce / (Ca + Ce), from 0 (maximally stable: only incoming dependencies) to 1 (maximally unstable: only outgoing dependencies). Chapter 3
Integration database: A database shared by several applications, which integrate through it by reading and writing the same tables. Martin Fowler (2004) advises against it because it couples the applications deeply. Chapter 7
Integration test: An automated test that checks that several parts work correctly together, such as code with a real database or another service's API. Chapter 0
Interaction mode: In Team Topologies, one of three deliberate ways two teams work together: collaboration, X-as-a-Service or facilitating. Modes are expected to change as boundaries are discovered and settle. Chapter 11
Interest (of technical debt): The extra effort, delay or risk paid on every change because the debt has not been repaid. Chapter 1
Interface: The agreed set of operations a piece of software offers to others, with their inputs and outputs: a contract that hides how the work is done. Chapter 0
Interface segregation principle (ISP): Clients should not be forced to depend on operations they do not use; prefer several small, client-specific interfaces to one large one. Chapter 3
Internal developer platform (IDP): The set of self-service tools, services, templates and documentation that an organisation's platform team provides so that product teams can build and run software without tickets. Chapter 10
Interoperability: The degree to which systems can exchange information and correctly use what they exchange, which needs agreement on meaning as well as format. Chapter 2
Interpreter: A program that reads code and carries out its instructions as it goes, rather than translating the whole program in advance. Chapter 0
Invariant: A condition that is always true for a module or object between operations, such as 'an account balance never goes below its overdraft limit'. Chapter 3
Inverse Conway manoeuvre: Deliberately shaping teams and their communication paths to match the architecture you want, so that Conway's law works for you rather than against you. Chapter 3
Inversion of control: The arrangement in which a framework, rather than your own code, controls the flow of the program and calls your code when needed. Chapter 0
IP address: The numeric address that identifies a device on a network so packets can be delivered to it, such as 192.0.2.10 (IPv4) or 2001:db8::1 (IPv6). Chapter 0
ISO/IEC 25010: The international standard product quality model. The 2023 edition defines nine characteristics, from functional suitability to safety, each divided into sub-characteristics. Chapter 2
ISO/IEC 42001: The international standard (2023) specifying requirements for a certifiable AI management system within an organisation. Chapter 12
Isolation level: A setting that says how much concurrent transactions may affect each other: read uncommitted, read committed, repeatable read, snapshot or serializable. Names mean different things in different databases. Chapter 7

J

Jailbreak: An input designed to make a model break the safety policies its provider trained into it. Chapter 12
Jitter: Randomness added to retry delays or schedules so that many clients do not act at the same moment and create synchronised spikes. Chapter 9
Join: An SQL operation that combines rows from two or more tables by matching related columns, such as orders with the customers who placed them. Chapter 0
Joint ownership: A situation in which a few services all write the same data. It can be resolved by splitting the table, a small shared data domain, delegating writes to one owner or merging the services. Chapter 7
JSON (JavaScript Object Notation): A text format for structured data made of objects (name-value pairs in braces), arrays (lists in brackets), strings, numbers, true, false and null. Standardised in RFC 8259. Chapter 0
JSON Web Token (JWT): A compact, signed (and optionally encrypted) token carrying claims such as issuer, subject, audience and expiry, defined in RFC 7519; widely used for access tokens and ID tokens. Chapter 8
Just-enough documentation: Documentation sized to what its readers actually need, so that writing and maintaining more would cost more than it returns. Chapter 4

K

Kanban: A way of managing work as a continuous flow on a visual board, limiting how many items may be in progress at once. Chapter 0
Key management service (KMS): A managed service that creates, stores, rotates and controls use of cryptographic keys, performing operations with them so that applications never see the master keys. Chapter 8
Key-value store: A database that stores values under unique keys and retrieves them only by key, like a very large, very fast dictionary. Chapter 0
KISS: Keep it simple: a design rule of thumb, from 1960s engineering, that unnecessary complexity should be avoided because it makes a system harder to understand, operate and repair. Chapter 3
Knowledge pyramid: A model with three layers: what you know, what you know you do not know, and what you do not know you do not know. Architects deliberately widen the middle layer. Chapter 1
Kubernetes: The most widely used open-source container orchestrator, created at Google, announced in 2014 and released as version 1.0 in 2015; it keeps a cluster's actual state matching a declared desired state. Chapter 10

L

Lakehouse: An architecture that adds warehouse features such as transactions, schemas and fast queries to data held in open file formats on object storage. Chapter 7
Large language model (LLM): A very large transformer trained on huge amounts of text to predict the next token, then tuned to follow instructions; it generates text, code and structured data. Chapter 12
Last responsible moment: The point at which delaying a decision any further would remove an important option; deciding then uses the most information without causing harm. Chapter 1
Last write wins: A conflict-resolution rule that keeps the write with the latest timestamp and discards the others. Simple, but concurrent updates are silently lost and clock differences can pick the wrong winner. Chapter 6
Latency: The delay before data arrives or a response comes back, usually measured in milliseconds. Distance, network hops and slow processing all add to it. Chapter 0
Latency budget: The share of an end-to-end response-time target allocated to each step or service on a request's path, so that each team knows the limit it must stay within. Chapter 11
Lateral movement: An attacker's progress from the first machine or account they compromise to other systems inside the same network or organisation. Chapter 8
Lawful basis: One of the six grounds in GDPR Article 6 (consent, contract, legal obligation, vital interests, public task, legitimate interests) on which processing of personal data must rest. Chapter 8
Layer: A group of components with the same technical responsibility, which offers services to the layer above and uses the layer below. Chapter 5
Layer 4 load balancer: A load balancer that works at the transport level (TCP or UDP), forwarding connections or packets without reading the HTTP request inside them. Chapter 9
Layer 7 load balancer: A load balancer that understands the application protocol, usually HTTP, so it can route each request by path, header or cookie, terminate TLS and retry. Chapter 9
Layered architecture: A style that arranges components in horizontal layers, each with one technical role, where each layer uses only the layers beneath it. Chapter 5
Layering: Arranging modules in layers where each layer may use only the layers below it. Strict layering allows only the layer directly below; relaxed layering allows any lower layer. Chapter 3
Layers of isolation: The property that a change inside one layer does not ripple into other layers while its interface stays the same; it depends on layers being closed. Chapter 5
LCOM (lack of cohesion of methods): A family of class-level metrics that estimate cohesion from how the methods of a class share its fields; a high value suggests the class holds several unrelated responsibilities. Chapter 3
Leader-follower replication: A replication scheme in which one node (the leader or primary) accepts all writes and streams its changes to followers (replicas), which can serve reads. Chapter 7
Leaderless replication: A Dynamo-style scheme in which clients write to and read from several replicas directly and use quorums instead of a single leader. Chapter 7
Leaky abstraction: An abstraction whose hidden details still affect its users, for example a remote call that looks like a local one until the network is slow or fails. Named by Joel Spolsky in 2002. Chapter 3
Leaky bucket: A rate-limiting or traffic-shaping algorithm in which requests enter a bucket and leave at a constant rate; when the bucket is full, new requests are rejected. Chapter 9
Least connections: A load-balancing algorithm that sends each new request to the instance with the fewest requests or connections currently in progress. Chapter 9
Least frequently used (LFU): An eviction policy that removes the item that has been read least often when the cache is full. Chapter 7
Least privilege: The principle that every user, program and service gets only the permissions it needs for its job, for only as long as it needs them, so that a mistake or compromise does limited damage. Chapter 8
Least recently used (LRU): An eviction policy that removes the item that has gone longest without being read when the cache is full. Chapter 7
Legacy system: An existing system that still delivers value but has become hard, risky or expensive to change, often because of age, missing tests, scarce skills or unsupported technology. Chapter 11
Lethal trifecta: Simon Willison's name (2025) for the dangerous combination of access to private data, exposure to untrusted content and the ability to communicate externally. Chapter 12
Library: Reusable code written by someone else that your code calls when it needs it, such as a library for dates or for sending email. Chapter 0
Lifeline: In a sequence diagram, the dashed vertical line below a participant, along which its messages and activations are shown in time order. Chapter 4
Linearisability: The strongest single-object consistency model: every operation appears to happen at one instant between its start and end, in an order all clients share and that respects real time, as if there were one copy. Chapter 6
Linux: A free, open-source operating system kernel, used with other software as the operating system on most servers, cloud machines and containers, as well as Android phones. Chapter 0
Liskov substitution principle (LSP): Anything that claims to be a subtype must be usable wherever its supertype is expected without the caller noticing a difference in behaviour. Named after Barbara Liskov. Chapter 3
Little's law: The rule L = λ × W: the average number of items in a stable system equals the average arrival rate multiplied by the average time each item spends in it. Chapter 2
Liveness probe: A health check that asks whether a process is stuck beyond recovery; failing it causes the orchestrator to restart the instance. Chapter 9
Living documentation: Documentation that evolves with the system it describes, often because it is generated from or checked against the system itself. Chapter 4
LLM-as-judge: Using a language model to score or compare outputs against a rubric; scalable but subject to biases that must be measured against human judgement. Chapter 12
LLMOps: Practices for building, releasing, monitoring and improving applications based on large language models, including versioning prompts and models, tracing calls and evaluation in the pipeline. Chapter 12
Load balancer: A component that receives incoming requests and spreads them across several servers, skipping any that are unhealthy. Chapter 0
Load shedding: Deliberately rejecting some requests, cheaply and early, when a system is overloaded, so that the requests it accepts still succeed in time. Chapter 9
Load test: A performance test that applies the expected (or forecast peak) load for a period to check that latency and error targets are met. Chapter 9
Locality (of connascence): How close together the connascent elements are: within one function, one module, one component or across a network. Strong connascence is tolerable only when it is local. Chapter 3
Lock-in: The cost and difficulty of switching away from a vendor, product, platform or technology once a system depends on it. Chapter 10
Lockfile: A file generated by a package manager that records the exact versions, and usually hashes, of every dependency resolved, so that every install uses the same packages. Chapter 8
Logical module: A unit of responsibility in the design, such as Ordering or Payments, regardless of how its code is packaged or deployed. Chapter 3
Lost update: An anomaly in which two transactions read a value, each computes a new one and writes it back, so one change silently overwrites the other. Chapter 7

M

Machine code: Instructions encoded as numbers that a particular family of CPU can execute directly. Machine code for one family (for example x86-64) does not run on another (for example Arm). Chapter 0
Machine learning: Building a function from examples instead of hand-written rules: a model is fitted to data and then used to make predictions about new inputs. Chapter 12
MADR: Markdown Architectural Decision Records: a widely used ADR template with decision drivers, considered options, the outcome, consequences and confirmation. Chapter 4
Magic value: A literal number or string whose meaning is not stated in the code, such as a status of 3 meaning 'shipped'. It creates connascence of meaning between everything that uses it. Chapter 3
Main sequence: The line A + I = 1 on a graph of abstractness against instability, where well-balanced components lie. Distance from it is D = |A + I - 1|. Chapter 3
Maintainability: In ISO/IEC 25010, how effectively and efficiently a product can be modified, covering modularity, reusability, analysability, modifiability and testability. Chapter 2
Managed database: A database service run by a cloud provider, which handles installation, patching, backups and failover while the customer manages the schema, queries and access. Chapter 0
Managed service: A cloud service, such as a database, queue or storage service, that the provider installs, operates, patches and scales, so that customers use it without running it. Chapter 0
Mean time between failures (MTBF): The average time from one failure of a repairable component or system to the next. Chapter 2
Mean time to failure (MTTF): The average time a component runs correctly before it fails. Chapter 2
Mean time to repair (MTTR): The average time from a failure until the service is restored. Some organisations read the R as recover or restore; always say which start and end points are measured. Chapter 2
Mediator topology: An event-driven topology in which a mediator receives an initiating event and directs the workflow by sending commands to processors in a defined order. Chapter 6
Message: Any data sent from one program to another through a channel; it may carry an event, a command, a query or a reply. Chapter 6
Message queue: Software that stores messages from senders until receivers are ready to process them, so the two need not be running or fast at the same time. Chapter 0
Microkernel architecture: An architectural style, also called a plug-in architecture, in which a small core system provides the general workflow and independent plug-ins add or change behaviour through published contracts. Chapter 5
Microsegmentation: Dividing a network into very small zones, down to single workloads, so that each one accepts traffic only from the callers it needs. Chapter 8
Microservice premium: Martin Fowler's term (2015) for the extra cost and risk that microservices add, which only pays off once a system and organisation are complex enough. Chapter 5
Microservices: A style in which an application is built as small services, each in its own process, built around a business capability, independently deployable and communicating through lightweight mechanisms. Chapter 6
Migration: A versioned script that changes a database schema or its data from one version to the next, kept in version control and applied automatically. Chapter 7
Mirroring hypothesis: The research version of Conway's law: the technical dependencies in a product tend to match the communication and organisational ties among the people who build it. Chapter 3
Model card: A short document published with a model describing its intended use, evaluation results across groups, training data, limitations and ethical considerations (Mitchell et al., 2019). Chapter 12
Model cascade: A design that sends a request to a cheaper model first and escalates to a more capable one only when a check says the first answer is not good enough. Chapter 12
Model Context Protocol (MCP): An open protocol, introduced by Anthropic in November 2024 and now governed under the Linux Foundation, for connecting AI applications to servers that expose tools, data and prompts. Chapter 12
Model kind: In ISO/IEC/IEEE 42010, the conventions for one type of model, such as a UML sequence diagram or a C4 container diagram. Chapter 4
Modelling tool: A tool that stores elements and relationships in a model and generates diagrams as views of it, keeping every view consistent. Chapter 4
Modifiability: How cheaply and safely a system can be changed: the cost, effort and risk of a change, and how far it ripples beyond the place where it is made. Chapter 2
Modular monolith: A single deployable application whose code is divided into modules along business boundaries, each with an explicit public interface and its own data. Chapter 5
Modularity: The degree to which a system is divided into parts that can be understood, changed and tested largely on their own. A sub-characteristic of maintainability in ISO/IEC 25010. Chapter 3
Module: A unit of code, often a single file, that groups related functions and data under one name and decides what it makes available to other code. A package is a group of modules. Chapter 0
Module API: The small, deliberately public part of a module that other modules may use; everything else is internal and free to change. Chapter 5
Module view: A view of the units of implementation (packages, libraries, layers) and their dependencies, as they exist at development time. Chapter 4
Monitoring: Collecting and watching predefined measurements and checks so that known kinds of failure are detected and reported. Chapter 9
Monolith: A system built and deployed as a single unit, even if its code is divided into well-separated modules inside. Chapter 1
MonolithFirst: Martin Fowler's 2015 advice to start a new system as a well-modularised monolith and extract services later, when boundaries are understood and needed. Chapter 5
Monolithic architecture: An architecture in which the whole application is built and deployed as a single unit, whatever its internal structure. Chapter 5
Monotonic reads: A guarantee that once a client has seen a value, its later reads never return an older one, so data never appears to go back in time. Chapter 6
Multi-cloud: Using services from two or more public cloud providers, for distinctive services, acquisitions, leverage or regulatory exit plans. Chapter 10
Multi-factor authentication (MFA): Authentication that requires two or more different kinds of factor: something you know, something you have and something you are. Chapter 8
Multi-leader replication: A scheme in which several nodes accept writes and replicate to each other, requiring a way to detect and resolve conflicting writes. Chapter 7
Multi-version concurrency control (MVCC): A technique in which writes create new row versions instead of overwriting, so readers see a consistent snapshot without blocking writers. Chapter 7
Multiplicity: In a UML class diagram, how many objects may take part at each end of an association, such as 1, 0..1, 0..* or 1..*. Chapter 4
Multiwindow, multi-burn-rate alert: An SLO alert that fires only when the burn rate is above a threshold over both a long window and a short window, combining fast detection with quick reset and few false alarms. Chapter 9
Mutual TLS (mTLS): TLS in which both sides present and verify certificates, so that a service knows which service is calling it as well as the caller knowing the server. Chapter 8

N

N+1 query problem: A performance fault in which code makes one query to fetch a list of N items and then one more query per item, giving N+1 round trips where one or two would do. Chapter 6
Net present value (NPV): The sum of an investment's future cash flows, each discounted back to today's value, minus the initial cost; a positive NPV means the investment earns more than the discount rate. Chapter 11
Network partition: A network fault that splits a system into groups of nodes that cannot communicate with each other, although each group may still be running and reachable by some clients. Chapter 6
NIST AI RMF: The voluntary AI Risk Management Framework published by the US National Institute of Standards and Technology (version 1.0, 2023), built on the functions Govern, Map, Measure and Manage. Chapter 12
Non-functional requirement (NFR): A widely used but imprecise name for quality requirements and constraints. Many architects avoid it because these requirements qualify functions rather than standing apart from them. Chapter 2
Non-risk: A decision judged sound for a given scenario, recorded together with the assumptions it depends on, so that it can be re-examined if those assumptions change. Chapter 11
NoSQL: An umbrella term for databases that do not use the relational table model, such as document, key-value, wide-column and graph databases. Chapter 0

O

OAuth 2.0: The delegated authorisation framework of RFC 6749, in which an authorisation server issues access tokens that let a client call a resource server on a resource owner's behalf, without seeing their password. Chapter 8
Observability: How well people can understand what is happening inside a running system from the data it emits (logs, metrics, traces), including for problems nobody anticipated. Chapter 2
Offline evaluation: Evaluating a version of an AI system against fixed datasets before it reaches users. Chapter 12
Offset: The sequential position of an event within a partition; consumers record the offset they have reached so they can resume after a restart. Chapter 6
OLAP: Online analytical processing: workloads of large queries that scan and aggregate many records, such as revenue by region by month. Chapter 7
OLTP: Online transaction processing: workloads of many small reads and writes of individual records, such as placing orders or posting payments. Chapter 7
One-page architecture summary: A single page giving a system's purpose, quality goals, context, main building blocks, key decisions and risks, as the front door to fuller documentation. Chapter 4
Online evaluation: Evaluating an AI system on live traffic, for example through shadow deployments, canaries or A/B tests. Chapter 12
Open Container Initiative (OCI): A Linux Foundation project, founded in 2015, that maintains open standards for container image formats, runtimes and registries, so that tools from different vendors interoperate. Chapter 10
Open host service: A context-map pattern in which an upstream context offers one well-defined, documented protocol or API for all its consumers. Chapter 5
Open layer: A layer that the layer above is allowed to bypass, typically a layer of shared services that only some requests need. Chapter 5
Open table format: A specification, such as Apache Iceberg, Delta Lake or Apache Hudi, that organises data files and metadata so many engines can treat them as tables with transactions and time travel. Chapter 7
Open workload model: A load model in which new requests arrive at a set rate regardless of how quickly earlier ones are answered, like customers arriving at a website. Chapter 9
Open-closed principle (OCP): A module should be open for extension but closed for modification: new behaviour should be added by adding code, such as a new implementation of an interface, not by editing working code. First stated by Bertrand Meyer in 1988. Chapter 3
Open-weight model: A model whose trained weights are published for others to run, under a licence that may be permissive or restrictive. Open weights do not by themselves make a model open source. Chapter 12
OpenAPI: A standard, machine-readable format for describing HTTP APIs (paths, operations, parameters, schemas), formerly the Swagger specification. It drives documentation, code generation and testing. Chapter 6
OpenID Connect (OIDC): An identity layer on top of OAuth 2.0 that adds an ID token, a signed JWT telling the client who the user is and how and when they authenticated. Chapter 8
OpenTelemetry: A vendor-neutral, open-source CNCF project that provides APIs, SDKs, a protocol (OTLP) and a collector for producing and exporting traces, metrics and logs. Chapter 9
OpenTofu: An open-source fork of Terraform created in 2023 after HashiCorp moved Terraform to the Business Source Licence; hosted by the Linux Foundation and a CNCF project. Chapter 10
Operating system: The software that manages a computer's hardware and shares it between programs: CPU time, memory, files, network and security. Examples are Linux, Windows, macOS, Android and iOS. Chapter 0
Optimistic concurrency control: Detecting conflicts instead of preventing them: a write succeeds only if a version number or timestamp is unchanged since the data was read, otherwise the writer retries. Chapter 7
Orchestration: Coordination of a multi-step process by one component that tells each participant what to do and decides what happens next. Chapter 6
Overfitting: When a model learns quirks of its training data instead of the general pattern, so it scores well on examples it has seen and badly on new ones. Chapter 12

P

PaaS (platform as a service): A cloud model in which you supply your application code or container and the provider runs, patches and scales the platform underneath it. Chapter 0
PACELC: Daniel Abadi's extension of CAP: if there is a Partition, trade Availability against Consistency; Else, in normal operation, trade Latency against Consistency. Chapter 6
Package manager: A tool such as pip (Python) or npm (JavaScript) that downloads libraries and the libraries they depend on, at the versions a project specifies. Chapter 0
Packet: A small chunk of data sent across a network with addressing information attached. Large messages are split into many packets and reassembled at the other end. Chapter 0
Parallel run: Running the old and new implementations side by side on the same inputs and comparing their results, while the old one stays authoritative, to prove the new one is equivalent before switching. Chapter 11
Partial failure: A situation in which some parts of a distributed system work while others have failed, are slow or cannot be reached, often without the working parts being able to tell which. Chapter 6
Partition (of a topic): In Kafka and similar logs, one ordered, append-only part of a topic. Events with the same key go to the same partition; order is guaranteed only within it. Chapter 6
Partitioning (sharding): Splitting a data set so that each machine holds only part of it, chosen by a partition key, to scale writes and storage beyond one machine. Chapter 7
Passkey: A FIDO2/WebAuthn credential: a key pair created for one website, whose private key stays on the user's device or password manager, which makes login phishing-resistant and leaves no shared secret on the server. Chapter 8
Password hashing: Storing a password as the output of a deliberately slow, salted function such as Argon2id, scrypt or bcrypt, so that a stolen database cannot be cheaply turned back into passwords. Chapter 8
Paved road (golden path): A supported, well-documented default way to build and run software, such as a service template with logging, security and deployment already set up, which teams may leave when they have good reason. Chapter 11
Pay-as-you-go: A pricing model in which you are charged for resources only while you use them, for example per second of server time or per gigabyte stored. Chapter 0
Payback period: How long it takes for cumulative benefits to repay an investment's cost; the discounted payback period does the same with discounted cash flows. Chapter 11
Percentile (p95, p99): The value below which a given share of measurements fall. A p99 of 400 ms means 99% of requests took 400 ms or less and 1% took longer. Chapter 2
Performance budget: An agreed limit on a performance measure, such as page weight or p99 latency per service call, that a change must not exceed, ideally checked automatically. Chapter 9
Perimeter security: The traditional model that protects a trusted internal network with firewalls and VPNs and treats anything already inside as friendly; sometimes called castle-and-moat security. Chapter 8
Personal data: Under the GDPR, any information relating to an identified or identifiable natural person (a living individual), such as a name, an ID number, location data or an online identifier. Chapter 8
Personal data breach: Under GDPR Article 4(12), a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Chapter 8
Perspective: In Rozanski and Woods's approach, a quality concern such as security or performance that is applied across all views, rather than drawn as a view of its own. Chapter 4
Pessimistic locking: Preventing conflicts by locking rows when they are read (for example with SELECT ... FOR UPDATE), so other transactions wait until the lock is released. Chapter 7
Physical module: A unit that is built, versioned or deployed, such as a JAR file, a Python package, a container image or a service. One logical design can be packaged into physical modules in many ways. Chapter 3
Pilot light: A disaster recovery strategy that keeps data replicated and core infrastructure provisioned in a second region, but starts and scales the application servers only during a disaster. Chapter 10
Pipe: A one-way channel that carries data from one filter to the next, usually with a buffer between them. Chapter 5
Pipes and filters: A style in which data flows through a chain of independent processing steps (filters) connected by one-way channels (pipes). Chapter 5
PKCE: Proof Key for Code Exchange (RFC 7636): the client sends a hash of a one-time secret when it starts the authorisation code flow and the secret itself when it redeems the code, so a stolen code is useless. Chapter 8
Platform engineering: The discipline of building and running internal platforms that let product teams provision, deploy and operate software through self-service. Chapter 10
Platform team: A team that provides internal services, tools and infrastructure as a self-service product so that stream-aligned teams can deliver without deep expertise in the underlying technology. Chapter 11
Plug-in: A separately built module that adds behaviour to a host application through a contract the host publishes, without the host's code being changed. Chapter 5
Plug-in contract: The published interface between a core system and its plug-ins: the operations, data types, error behaviour and version that both sides agree to. Chapter 5
Plug-in registry: The part of a core system that records which plug-ins are available, their names, versions and contracts, so the core can find them without naming them in code. Chapter 5
Pod: The smallest deployable unit in Kubernetes: one or more containers scheduled together on one node, sharing a network address and storage volumes. Chapter 10
Policy as code: Writing rules about infrastructure and deployments (no public storage, required encryption, approved regions) as code that tools check automatically before or during changes. Chapter 10
Policy decision point (PDP): The component that evaluates access policy and answers allow or deny; a policy enforcement point (PEP) asks it and then enforces the answer. Chapter 8
Policy enforcement point (PEP): The component in the traffic path, such as a proxy, gateway or sidecar, that allows or blocks each request according to a policy decision. Chapter 8
Polyglot persistence: Using different kinds of database for different data within one system, chosen by how each data set is used, at the cost of more technologies to run. Chapter 7
Port: A number from 0 to 65535 that identifies which program on a device should receive network traffic, such as 443 for HTTPS. Chapter 0
Ports and adapters (hexagonal architecture): Alistair Cockburn's style in which an application talks to the outside world only through ports (interfaces it owns), and adapters translate between each port and a particular technology. Chapter 5
Post-incident review: A structured meeting and written report after an incident that reconstructs what happened, why it made sense to the people involved and what will change; also called a postmortem. Chapter 9
Postcondition: A condition an operation guarantees to be true when it finishes, provided its precondition was met. Chapter 3
Power of two random choices: A load-balancing method that picks two instances at random and sends the request to the less loaded one; Mitzenmacher showed it balances almost as well as checking every instance. Chapter 9
Power/interest grid: A two-by-two map placing stakeholders by their power over a project and their interest in it, used to plan how closely to engage each group. Chapter 1
Pre-mortem: Gary Klein's technique (2007) in which a team imagines that its project has already failed and each person writes down why, which surfaces risks that people are otherwise reluctant to raise. Chapter 11
Precision and recall: Precision is the share of items a model flags that are really positive; recall is the share of real positives the model catches. Raising one usually lowers the other. Chapter 12
Precondition: A condition that must be true before an operation is called; meeting it is the caller's obligation. Chapter 3
Primary key: A column, or set of columns, whose value uniquely identifies each row in a table, such as customer_id. Chapter 0
Principal (of technical debt): The effort needed to fix a piece of technical debt, that is, to bring the code or structure to the state it should be in. Chapter 1
Private cloud: Cloud infrastructure dedicated to one organisation, offering self-service, API-driven provisioning; it may be on premises or hosted by a third party. Chapter 10
Probe (liveness, readiness, startup): A periodic check by Kubernetes on a container: liveness decides whether to restart it, readiness whether to send it traffic, startup whether it has finished starting. Chapter 10
Problem details (RFC 9457): A standard JSON format for HTTP API errors, with members type, title, status, detail and instance, served as application/problem+json. RFC 9457 (2023) replaced RFC 7807. Chapter 6
Process: A running instance of a program, with its own private memory and share of CPU time, created and managed by the operating system. Chapter 0
Processor: An organisation that processes personal data on behalf of a controller, under its instructions and a contract, such as a cloud SMS or e-mail provider. Chapter 8
Production: The live environment that real users and real data depend on. Chapter 0
Program: A list of precise instructions that a computer follows to do a job. A running program is called a process. Chapter 0
Progressive delivery: Releasing a change to gradually larger audiences with automated checks at each step, so that a bad change reaches as few users as possible before it is stopped. Chapter 10
Projection: Code that listens to changes or events and keeps a read model up to date; also used for the read model it produces. Chapter 7
Prompt: Everything sent to a language model in one call: system instructions, conversation history, retrieved documents, tool definitions and the user's message. Chapter 12
Prompt caching: Reuse of a model's computed state for an identical prompt prefix seen recently, which lowers the cost and latency of the repeated part. Chapter 12
Prompt injection: An attack in which text supplied by a user or hidden in content the model reads contains instructions that override or subvert the application's intended behaviour. Chapter 12
Proof of concept: A small, time-boxed piece of working code built to test whether an idea, technology or design choice works before committing to it. Chapter 1
Protocol Buffers: A language-neutral, compact binary format for structured data, defined in .proto files in which each field has a permanent number. Used by gRPC and many messaging systems. Chapter 6
Provenance: Verifiable information about where an artefact came from: which build platform built it, from which source revision, with which inputs and parameters. Chapter 8
Provided interface: In a UML component diagram, an interface a component offers to others, drawn as a small circle (a ball) on a stick. Chapter 4
Pseudonymisation: Processing personal data so that it can no longer be linked to a person without additional information kept separately; under the GDPR, pseudonymised data is still personal data. Chapter 8
Psychological safety: A shared belief within a team that it is safe to take interpersonal risks such as admitting mistakes or challenging a senior colleague; studied by Amy Edmondson since 1999. Chapter 11
Public key infrastructure (PKI): The certificate authorities, certificates, trust stores, policies and revocation mechanisms that together let parties verify each other's public keys. Chapter 8
Publish-subscribe: A messaging pattern in which a publisher sends a message to a topic and every subscriber receives its own copy, without the publisher knowing who they are. Chapter 6
Published language: A documented, shared format for exchanging information between contexts, such as a versioned event schema, often offered through an open host service. Chapter 5
Pull request: A request to merge a branch into the main line, on a service such as GitHub, where colleagues review the change and automated checks run before it is accepted. Chapter 0

Q

Quality attribute: A measurable property of a system that says how well it does its job, such as performance, availability, security or modifiability. Chapter 2 covers them in depth. Chapter 1
Quality attribute scenario: A short, testable statement of a quality requirement with six parts: source of stimulus, stimulus, artifact, environment, response and response measure. Chapter 2
Quality Attribute Workshop (QAW): A facilitated SEI method in which stakeholders brainstorm, consolidate, vote on and refine quality attribute scenarios early in a project. Chapter 2
Quality in use: The quality a product delivers to people in a specific context of use (whether it is beneficial, free from risk and acceptable). Since 2023 it has its own standard, ISO/IEC 25019. Chapter 2
Quality model: A structured list of quality characteristics and their sub-characteristics, used as shared vocabulary and as a checklist when specifying or evaluating quality. Chapter 2
Queue (point-to-point channel): A messaging channel in which each message is delivered to exactly one of the consumers reading from it, so several instances can share the work. Chapter 6
Queueing: Waiting for a busy resource. Queueing theory studies how waiting time grows with utilisation; it explains why response time rises sharply as a resource nears 100% busy. Chapter 2
Quorum (R + W > N): In a store with N replicas, a write waits for W acknowledgements and a read for R replies; if R + W > N, every read set overlaps every write set in at least one replica. Chapter 6

R

RAM (memory): Random-access memory: fast, temporary storage holding the programs and data in use right now. Its contents are lost when the power goes off or the program ends. Chapter 0
Rate limit: A cap on how many requests a client may make in a period, such as 100 per minute. Requests above it are refused, typically with HTTP status 429. Chapter 0
Rate limiting: Restricting how many requests a client, key or tenant may make in a period, to protect capacity and share it fairly; excess requests are usually answered with HTTP 429. Chapter 9
Re-ranking: A second retrieval stage in which a more accurate but slower model rescores the top candidates from the first stage and keeps the best few. Chapter 12
ReAct: Reasoning and acting (Yao and colleagues, 2022): a pattern in which a model interleaves reasoning steps with actions and uses each observation to decide the next step. Chapter 12
Read replica: A copy of a database that receives the primary's changes and serves read queries, reducing load on the primary at the cost of slightly stale data. Chapter 5
Read-your-writes: A guarantee that after a client writes a value, that client's own later reads see the write or something newer, even if other clients do not yet. Chapter 6
Readiness probe: A health check that asks whether an instance can serve traffic right now; failing it removes the instance from the load balancer without restarting it. Chapter 9
Reasoning model: A language model trained to generate intermediate reasoning tokens before answering, trading extra cost and latency for better results on hard multi-step tasks. Chapter 12
Reconciliation loop: A controller's endless cycle of observing the actual state, comparing it with the desired state and acting to remove the difference. Chapter 10
Recovery point objective (RPO): The largest amount of data, measured as a period of time, that the business can accept losing in a disaster, for example the last 15 minutes of changes. Chapter 2
Recovery time objective (RTO): The longest time the business can accept between a disaster and the restoration of the service. Chapter 2
RED method: Tom Wilkie's checklist for monitoring request-driven services: Rate, Errors and Duration of requests. Chapter 9
Red teaming: Deliberate adversarial testing in which people or tools try to make a system misbehave, leak data or cause harm, so that weaknesses are found before attackers find them. Chapter 12
Redundancy: Keeping more than one copy of a component so that another can take over if one fails. Chapter 2
Refactoring: Changing the internal structure of code without changing its external behaviour, to make it easier to understand and modify. Chapter 1
Reference architecture: A template architecture for a domain or platform that maps typical functions onto a standard set of parts, which projects adapt instead of designing from scratch. Chapter 5
Region: A geographic area, such as Western Europe or East US, where a cloud provider operates a separate group of data centres. Regions are isolated from each other. Chapter 0
Regression eval: An automated evaluation that runs whenever prompts, models, retrieval or tools change and blocks the release if quality falls below a threshold or baseline. Chapter 12
Reinforcement learning: Machine learning in which an agent takes actions and learns from a reward signal rather than from correct answers. Chapter 12
Reinforcement learning from human feedback (RLHF): A training stage in which people compare model answers, a reward model learns their preferences and the model is optimised to score well on it. Chapter 12
Relation: A connection between elements, such as one module using another, one service calling another, or a service being deployed on a server. Chapter 1
Relational database: A database that stores data in tables of rows and columns and links tables through keys. It is queried with SQL. Chapter 0
Relationship-based access control (ReBAC): Deciding access from relationships between users and objects (owner of, member of, works at), stored as a graph; Google's Zanzibar (2019) is the best-known example. Chapter 8
Reliability: The probability that a system performs correctly, without failure, for a stated period under stated conditions. A system can be highly available yet unreliable if it fails often but recovers quickly. Chapter 2
Replication: Keeping copies of the same data on several machines for availability, read capacity and lower latency near users. Chapter 7
Replication lag: The delay between a write on the leader and its appearance on a follower; it causes users to read stale data. Chapter 7
Repository: An object that loads and saves whole aggregates and looks to the domain like a collection, hiding how and where they are stored. Chapter 5
Reproducible build: A build that produces bit-for-bit identical output from the same source and inputs, so that anyone can rebuild and check that a published artefact was not tampered with. Chapter 8
Request coalescing: Letting only one request fetch a missing item while other requests for the same item wait for and share its result; also called single flight. Chapter 7
Required interface: In a UML component diagram, an interface a component needs another component to provide, drawn as a half-circle (a socket). Chapter 4
Requirement: A statement of something a system must do, or a quality it must have, agreed with the people who need it. Chapter 0
Resilience: The broader capacity of a system to absorb disruption, keep its essential service going (perhaps in a degraded form) and recover to normal afterwards. Chapter 2
Resource requests and limits: Per-container CPU and memory settings in Kubernetes: requests reserve capacity and guide scheduling; limits cap use, throttling CPU and killing containers that exceed memory. Chapter 10
Response measure: The number that makes a scenario testable, such as '99% within 800 ms', 'service restored within 2 minutes' or 'change completed in 3 person-days'. Chapter 2
Response time: The total time between a client sending a request and receiving the answer: the service time plus any waiting time in queues, plus network delays. Chapter 2
REST (Representational State Transfer): An architectural style for web APIs, described by Roy Fielding in 2000, in which clients act on resources identified by URLs using standard HTTP methods. Chapter 0
Retention schedule: A documented list of how long each category of data is kept, why, and what happens to it at the end of that period. Chapter 8
Retrieval-augmented generation (RAG): Retrieving relevant passages from your own sources at query time and supplying them to the model so that it answers from current, permitted and citable facts. Chapter 12
Retry budget: A limit on retries expressed as a share of normal traffic (for example 10%), so that retries help with occasional failures but cannot multiply load during an outage. Chapter 9
Retry storm: A surge of load created when many clients, often at several layers, retry failing requests at once, which keeps an overloaded service overloaded. Chapter 9
Reuse/release equivalence principle (REP): The unit of reuse is the unit of release: classes grouped into a component should make sense to release, version and reuse together. Chapter 3
Reversibility: How cheaply and safely a decision can be undone. Highly reversible decisions can be made quickly; irreversible ones deserve more analysis. Chapter 1
Rightsizing: Matching the size of provisioned resources (machine types, container requests, database tiers) to what a workload actually uses. Chapter 10
Risk (in architecture evaluation): An architectural decision, or a missing decision, that may prevent the system from meeting an important quality requirement or business goal. Chapter 11
Risk register: A maintained list of identified risks with their probability, impact, owner, mitigation and status, so that risks are tracked to closure rather than forgotten after a meeting. Chapter 11
Risk theme: A group of related risks that share an underlying cause, linked to the business drivers it threatens. Risk themes are usually the most useful output of an evaluation for managers. Chapter 11
Risk-driven model: George Fairbanks' approach in which the amount of architecture work is set by the risks a project faces: identify risks, apply techniques, evaluate the reduction. Chapter 1
Risk-storming: Simon Brown's collaborative technique in which people silently mark risks on architecture diagrams with sticky notes, scored by probability and impact, then converge and agree priorities and mitigations. Chapter 11
Role-based access control (RBAC): Granting permissions to roles and roles to users, so that access is managed by assigning people to roles such as support agent or restaurant manager. Chapter 8
Roll forward: Recovering from a bad release by deploying a new fix rather than returning to the previous version. Chapter 10
Rollback: Returning a system to an earlier known good state or release after a change causes problems. Chapter 2
Rolling deployment: Replacing the instances of a service a few at a time, so that old and new versions run side by side until all instances run the new version. Chapter 10
Rolling window: A measurement period that moves forward continuously, such as the last 28 days, as opposed to a calendar month that resets on the first. Chapter 9
Rough consensus: A decision reached when every objection has been considered and answered, though not necessarily accommodated; described in IETF RFC 7282. Chapter 4
Runbook: A written, tested procedure for handling a specific operational or security situation step by step, including how to verify and roll back each step. Chapter 8

S

SaaS (software as a service): Complete software used over the internet, usually through a browser or app, with the provider running everything. Chapter 0
Safety: Freedom from unacceptable risk of harm to people, property or the environment caused by the system, whether or not anyone acts maliciously. Chapter 2
Saga: A business transaction implemented as a sequence of local transactions, each paired with a compensating transaction, so that either all steps complete or completed steps are semantically undone. Introduced by Garcia-Molina and Salem in 1987. Chapter 6
Saga countermeasure: A design technique that reduces anomalies caused by sagas' lack of isolation, such as a semantic lock (a PENDING state), commutative updates or re-reading a value before updating it. Chapter 6
Saga orchestrator: A component that coordinates a saga by sending commands to participants, tracking progress in a persistent state machine and triggering compensations on failure. Chapter 6
Sandbox: An isolated environment with tightly limited permissions, network access and resources, in which untrusted code such as model-written code can run safely. Chapter 12
Scalability: A system's ability to handle more load by adding resources, ideally with a predictable and roughly proportional increase in capacity and cost. Chapter 2
Scale cube: Abbott and Fisher's model of three ways to scale: X axis (identical copies behind a load balancer), Y axis (split by function) and Z axis (split by data, such as by customer). Chapter 5
Scaling out (horizontal scaling): Handling more load by adding more machines and spreading the work across them, usually behind a load balancer. Chapter 0
Scaling up (vertical scaling): Handling more load by moving to a bigger machine with more processors or memory. Chapter 0
Schema: The declared structure of a database: its tables, columns, data types, keys and rules. Chapter 0
Schema registry: A service that stores every version of each message schema and rejects new versions that break the agreed compatibility rule. Chapter 7
Scrum: An agile framework in which a small team works in fixed cycles called sprints, of one month or less, with defined events, accountabilities and artefacts. Chapter 0
SDK (software development kit): A library, usually provided by an API's owner, that wraps the API's HTTP calls in ordinary functions for a particular programming language. Chapter 0
Search engine: A store built around an inverted index from words to documents, providing relevance-ranked, typo-tolerant full-text search; usually fed from a system of record. Chapter 7
Secondary index: An index on an attribute other than the primary or partition key. In a partitioned store it is either local to each partition or global and partitioned by the indexed value. Chapter 7
Secrets management: Storing, distributing, rotating and auditing credentials such as passwords, API keys and private keys in a dedicated vault rather than in code or configuration files. Chapter 8
Secure by default: Shipping a product whose out-of-the-box configuration is the safe one, so that users must deliberately choose to weaken protection rather than remember to switch it on. Chapter 8
Secure Software Development Framework (SSDF): NIST SP 800-218: a set of secure development practices grouped as prepare the organisation, protect the software, produce well-secured software and respond to vulnerabilities. Chapter 8
Semantic caching: Returning a stored response when a new query is similar in meaning to an earlier one, judged by comparing embeddings, without calling the model. Chapter 12
Semantic coupling: Dependence on shared meaning or business rules that is not visible in any interface, such as two services that must agree on what 'active customer' means. Chapter 3
Semantic versioning: A version-numbering convention, MAJOR.MINOR.PATCH, in which the major number changes for breaking changes, the minor for backward-compatible additions and the patch for fixes. Chapter 5
Sensitivity point: A property of one or more components or connections that is critical to achieving a particular quality response, such as the number of synchronous hops on the order path. Chapter 11
Sequence diagram: A UML diagram showing the messages exchanged between participants over time for one scenario, with time running down the page. Chapter 4
Sequential consistency: A consistency model in which all clients see operations in one agreed order that preserves each client's own order, but that order need not match real time. Chapter 6
Serializability: The strongest isolation guarantee: concurrent transactions produce the same result as if they had run one at a time in some order. Chapter 7
Server: A computer, or a program running on one, that waits for requests from other computers (clients) and answers them. Chapter 0
Serverless: A cloud model in which the provider runs your functions or workflows on demand and bills per use, so you do not manage servers yourself. Chapter 1
Serverless and FaaS (function as a service): A cloud model in which you upload individual functions that run only when an event triggers them; the provider handles all servers and you pay per execution. Chapter 0
Service (Kubernetes): A Kubernetes object that gives a changing set of pods one stable name and virtual address, and spreads traffic across them. Chapter 10
Service credit: A refund or discount owed to a customer under an SLA when the provider misses a promised service level. Chapter 9
Service discovery: A mechanism, such as a registry or DNS, through which clients find the current network addresses of healthy service instances. Chapter 6
Service level agreement (SLA): A contract with customers that states a service level and the consequences, such as service credits, if it is not met. Chapter 2
Service level indicator (SLI): A carefully defined measurement of service behaviour, such as the proportion of requests that succeed in under 300 ms. Chapter 2
Service level objective (SLO): An internal target for an SLI over a time window, such as 99.9% of requests successful over 30 days. Chapter 2
Service mesh: An infrastructure layer of network proxies, centrally configured, that provides service-to-service encryption, retries, timeouts, traffic control and telemetry. Chapter 6
Service time: The time a resource spends actually working on a request, excluding any time the request spends waiting for that resource. Chapter 2
Service-based architecture: A distributed style with a few coarse-grained, separately deployed domain services (typically 4 to 12) that often share one database; named by Mark Richards and Neal Ford. Chapter 6
Service-oriented architecture (SOA): An approach, dominant in enterprises from the early 2000s, that exposes business capabilities as shared services with explicit contracts, typically connected through an enterprise service bus. Chapter 6
Session guarantees: Per-client consistency promises, described by Terry and colleagues in 1994: read-your-writes, monotonic reads, monotonic writes and writes-follow-reads. Chapter 6
Seven Rs: The migration strategies AWS lists for moving applications to the cloud: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. They grew from Gartner's earlier five Rs. Chapter 11
Severity level: A predefined classification of how bad an incident is, such as SEV1 to SEV4, that decides who is called, how fast and how widely it is communicated. Chapter 9
Shadow traffic (dark launch): Copying real requests to a new version whose responses are compared or discarded but never returned to users, to test it under real load without user impact. Chapter 10
Shared kernel: A small part of a model, and its code, that two contexts explicitly agree to share and may change only with both teams' consent. Chapter 5
Shared responsibility model: The division of security and operational duties between a cloud provider, which secures the cloud itself, and the customer, which secures its data, identities and configuration in the cloud. Chapter 10
Shift left: Moving security (or testing) activities earlier in the development lifecycle, into requirements, design and coding, where problems are cheaper to fix than in production. Chapter 8
Showback: Reporting to each team or product the costs attributed to it, without actually charging its budget. Chapter 10
Shuffle sharding: Assigning each customer to a small, randomly chosen combination of resources, so that two customers rarely share all of theirs and one bad customer affects few others. Chapter 10
SIEM: Security information and event management: a system that collects security logs from many sources, correlates them and raises alerts when they match detection rules. Chapter 8
Sigstore: An open-source project for signing and verifying software artefacts with short-lived certificates tied to an identity and a public transparency log, avoiding long-lived signing keys. Chapter 8
Single responsibility principle (SRP): A module should be responsible to one actor: one group of people who ask for its changes. Code that changes for different reasons, at the request of different people, should be kept apart. Chapter 3
SLSA: Supply-chain Levels for Software Artifacts: a framework of increasing levels of assurance that an artefact was built from the expected source by a trustworthy, tamper-resistant build. Chapter 8
Snapshot: A stored copy of an aggregate's state at a known event version, used to avoid replaying a long stream from the beginning; it is a cache, not a source of truth. Chapter 7
Snapshot isolation: An isolation level in which each transaction reads a consistent snapshot of committed data from its start and conflicting writes to the same row are rejected. It prevents lost updates but allows write skew. Chapter 7
Soak test: A long performance test at normal load, run for hours or days, to reveal slow problems such as memory leaks or growing queues; also called an endurance test. Chapter 9
Socio-technical architecture: Designing the software structure and the team structure together, because each shapes the other. The idea goes back to socio-technical systems research at the Tavistock Institute, beginning with Eric Trist and Ken Bamforth's 1951 coal-mining study. Chapter 11
Software: Programs together with the data and configuration they need; the instructions that tell hardware what to do. Chapter 0
Software architecture: The fundamental structures of a software system and the significant decisions that shaped them: its main parts, how they relate, their important properties and the principles that guide how it is built and evolves. Chapter 1
Software bill of materials (SBOM): A machine-readable inventory of the components and dependencies in a piece of software, in a standard format such as SPDX or CycloneDX. Chapter 8
Software Carbon Intensity (SCI): A Green Software Foundation specification, published as ISO/IEC 21031:2024, that expresses software's carbon emissions as a rate: ((energy x grid carbon intensity) + embodied emissions) per functional unit. Chapter 2
Software Carbon Intensity (SCI): The Green Software Foundation's specification, published as ISO/IEC 21031:2024, that rates software as ((E × I) + M) per R: energy times grid carbon intensity plus embodied emissions, per functional unit. Chapter 11
Software composition analysis (SCA): Tools and practices that identify the open-source components in software and match them against databases of known vulnerabilities and licences. Chapter 8
Software design description (SDD): A document describing a software design in detail, whose content IEEE Std 1016-2009 specifies; common in contract-driven projects. Chapter 4
Software supply-chain attack: An attack that compromises something an organisation consumes, such as a dependency, build tool, update or registry, in order to reach that organisation and others downstream. Chapter 8
Software system (C4): In the C4 model, the highest level of abstraction: something that delivers value to its users, usually owned by one team or organisation. Chapter 4
SOLID: A mnemonic for five object-oriented design principles collected by Robert C. Martin: single responsibility, open-closed, Liskov substitution, interface segregation and dependency inversion. Chapter 3
Solution architecture: Architecture of a solution to one business problem, often spanning several applications, vendors and teams, such as a new online claims process for an insurer. Chapter 1
Source code: The human-readable text of a program, written in a programming language such as Python or Java, which is then compiled or interpreted so a computer can run it. Chapter 0
SPACE framework: A 2021 framework for developer productivity covering satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. Chapter 10
Space-based architecture: An architectural style that serves requests from many identical processing units holding data in replicated in-memory grids, updating the database asynchronously so that it is off the request path. Chapter 6
Span: One timed operation within a trace, such as an HTTP call or a database query, with a name, start time, duration, attributes and a link to its parent span. Chapter 9
Spike: A short, time-boxed investigation or prototype built to answer a technical question or reduce a risk, normally thrown away afterwards. Chapter 1
Spike test: A performance test that raises load suddenly, for example tenfold in seconds, to check autoscaling, queues and protection mechanisms. Chapter 9
Split brain: A failure in which two nodes both believe they are the leader and both accept writes, so their data diverges. Chapter 7
Spot capacity: Spare cloud capacity sold at a large discount that the provider can take back at short notice; suitable only for work that tolerates interruption. Chapter 10
SQL (Structured Query Language): The standard language for defining, querying and changing data in relational databases. You describe the result you want and the database works out how to get it. Chapter 0
Stable Abstractions Principle: Robert C. Martin's principle that a component should be as abstract as it is stable, so that stable components can still be extended. Chapter 3
Stable Dependencies Principle: Robert C. Martin's principle that a component should depend only on components that are more stable than itself: depend in the direction of stability. Chapter 3
Staff engineer: A senior individual contributor role, above senior engineer, that carries technical leadership across teams without managing people; principal engineer is usually the next level up. Chapter 1
Staff-plus engineer: A senior individual contributor (staff, principal or distinguished engineer) who exercises technical leadership across teams without managing people; a term popularised by Will Larson. Chapter 11
Stakeholder: A person, team or organisation with an interest in a system, such as users, sponsors, developers, operators, security officers or regulators. Chapter 1
Star schema: A dimensional model with a central fact table of measurements surrounded by dimension tables that describe them, such as date, customer and product. Chapter 7
State (infrastructure as code): The record an infrastructure tool keeps of which real resources correspond to which definitions in code, used to work out what to create, change or delete. Chapter 10
State machine diagram: A UML diagram showing the states an object can be in and the transitions between them, each triggered by an event. Chapter 4
Stateless (application): An application that keeps no per-user data in its own memory between requests, so any copy can handle any request and copies can be added or removed freely. Chapter 5
Stateless service: A service instance that keeps no data between requests in its own memory or disk, so any instance can handle any request and instances can be added or removed freely. Chapter 9
Static connascence: Connascence visible in the source code without running it, such as agreement on a name, a type, the meaning of a value, the order of parameters or an algorithm. Chapter 3
Static stability: The property that a system keeps working during a failure without having to make changes, such as launching new servers or updating configuration, at the moment of the failure. Chapter 10
Status page: A public or customer-facing page that reports current incidents and service health, updated by the incident's communications lead. Chapter 9
Steady-state hypothesis: In a chaos experiment, the prediction that a measurable sign of normal behaviour, such as orders per minute, will stay within bounds while a failure is injected. Chapter 9
Sticky session (session affinity): A load-balancer setting that sends all requests from one client to the same instance, usually so that session data held in that instance's memory can be found. Chapter 9
Stimulus: The event that a quality attribute scenario is about, such as a burst of requests, a server crash, a change request or an attack. Chapter 2
Strangler fig: An incremental modernisation approach, named by Martin Fowler, in which new components gradually take over behaviour from a legacy system behind an interception layer until the old system can be switched off. Chapter 11
Stream processing: Processing an unbounded flow of records continuously, each one shortly after it arrives. Chapter 5
Stream-aligned team: A long-lived, cross-functional team aligned to one flow of change, such as a product, user journey or business capability, that can build, run and change its part end to end. Most teams in an organisation should be of this type. Chapter 11
Strength (of connascence): How hard a form of connascence is to discover and to refactor. Name is the weakest form; dynamic forms such as timing, value and identity are among the strongest. Chapter 3
Stress test: A performance test that pushes load beyond the expected peak to see how the system fails and whether it recovers. Chapter 9
STRIDE: A mnemonic for six kinds of threat (spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege), created at Microsoft by Loren Kohnfelder and Praerit Garg in 1999. Chapter 8
Structure: A set of elements and the relations among them, seen from one angle: for example the code modules and their dependencies, or the running services and how they communicate. Chapter 1
Structured logging: Writing log entries as machine-readable key-value records (often JSON) with consistent field names, instead of free-text sentences. Chapter 9
Structured output: Model output constrained to a declared format, usually a JSON Schema, so that the application can parse and validate it reliably. Chapter 12
Structurizr: Simon Brown's tooling for the C4 model, in which a text-based model generates many consistent diagrams. Chapter 4
Sub-characteristic: A more specific quality within a characteristic of a quality model; for example, fault tolerance and recoverability are sub-characteristics of reliability in ISO/IEC 25010. Chapter 2
Subdomain: A distinct area of a business's activity, such as menus, ordering, payments or dispatch. Subdomains belong to the problem, whether or not software exists. Chapter 5
Supervised learning: Machine learning from labelled examples, where each training input comes with the right answer, such as payments marked fraudulent or genuine. Chapter 12
Supporting subdomain: A subdomain that is specific to the business and necessary for it, but is not where it competes; it deserves sound but simpler design. Chapter 5
Switching cost: The total effort, money and risk needed to move from one technology or provider to another. Chapter 10
Symmetric encryption: Encryption in which the same secret key encrypts and decrypts, such as AES; fast, so it is used for bulk data. Chapter 8
Synchronous call: A request in which the caller waits for the response before continuing, as in an ordinary HTTP API call. Chapter 0
Synchronous communication: An interaction in which the caller sends a request and waits for the reply before continuing, like a telephone call. Both sides must be available at the same moment. Chapter 6
System context diagram: A C4 diagram showing one system as a single box, the people who use it and the other systems it interacts with. Chapter 4
System of record: The authoritative source for a piece of data, whose value wins when copies disagree, such as a bank's core ledger for account balances. Chapter 7

T

Tactic: A design decision that influences how a system responds to a quality stimulus, such as caching to cut latency or redundancy to survive a crash. Tactics are the building blocks of patterns. Chapter 2
Tail latency: The response times of the slowest requests, usually described by high percentiles such as p99 or p99.9. At scale the tail often decides what users experience. Chapter 2
TARA: The Tiny Architectural Review Approach, Eoin Woods's lightweight method for reviewing an existing system by combining expert judgement with automated analysis of its code and runtime data. Chapter 11
TCP: Transmission Control Protocol: delivers a reliable, ordered stream of data between two programs, resending lost packets. Most web traffic has traditionally used it. Chapter 0
Team API: Everything a team offers to and expects from other teams: its code interfaces, documentation, versioning rules, ways of working, communication channels and how to request work from it. Chapter 11
Team cognitive load: The total amount of knowledge and mental effort a team needs to build, run and change the parts of a system it owns. When it exceeds the team's capacity, quality and speed fall. Chapter 3
Team Topologies: An approach to organising software teams for fast flow, set out by Matthew Skelton and Manuel Pais in the book of the same name (2019; second edition 2025): four team types, three interaction modes and team cognitive load as the main constraint. Chapter 11
Technical breadth: Knowing that many technologies and approaches exist, what they are good and bad at, and when to use them, even without deep hands-on expertise in each. Chapter 1
Technical debt: The extra future cost of change caused by shortcuts or by design that no longer fits, paid as slower and riskier work until it is repaid by improving the design. Chapter 1
Technical partitioning: Dividing a system's top-level structure by technical role, such as user interface, business logic and data access. Chapter 5
Technology radar: A periodically refreshed map of technologies and techniques, grouped into quadrants and placed in rings such as Adopt, Trial, Assess and Hold (renamed Caution in recent Thoughtworks editions), popularised by Thoughtworks. Chapter 11
Telemetry: Data a running system emits about its own behaviour: logs, metrics, traces, profiles and events. Chapter 9
Temperature: A sampling setting that sharpens (below 1) or flattens (above 1) the model's next-token probabilities, making output more repeatable or more varied. Chapter 12
Temporal coupling: In distributed systems, a dependency on another part being available and responsive at the same moment, as with a synchronous call. Elsewhere the term can mean a required order of calls, or (in version-control analysis) files that change together, which this chapter calls change coupling. Chapter 3
Test double: A stand-in for a real collaborator used in a test, such as a stub with canned answers, a fake with a simple working implementation, or a mock that checks the calls it receives. Chapter 2
Testability: How easily a system or component can be shown, by testing, to behave as intended, which depends on being able to control its inputs and state and observe its outputs. Chapter 2
Testing pyramid: A guide, from Mike Cohn, to the proportions of automated tests: many fast unit tests, fewer integration tests and only a few slow end-to-end tests. Chapter 0
Thinnest viable platform: The smallest set of shared services and documentation that genuinely speeds up product teams; Team Topologies' warning against building more platform than needed. Chapter 10
Thread: One sequence of instructions being executed inside a process. Threads in the same process share its memory, so they can work at the same time but must coordinate. Chapter 0
Threat modelling: A structured way of asking, about a design, what we are building, what can go wrong, what we will do about it and whether we did a good enough job. Chapter 8
Throughput: The amount of work a system completes per unit of time, such as 1,200 requests per second or 40,000 orders per hour. Chapter 2
Tier: A physical boundary at run time, such as a separate process or server. A layer is a logical boundary in the code; several layers can run in one tier. Chapter 5
Time to first token (TTFT): The delay between sending a request to a model and receiving the first token of its response. Chapter 12
Time to live (TTL): How long a cached item may be used before it is considered stale and must be refreshed or revalidated. Chapter 7
Time-series database: A database optimised for timestamped measurements that arrive in order, with compression, downsampling and cheap deletion of old data. Chapter 7
Timeout: The maximum time a caller will wait for an operation before giving up and treating it as failed; every remote call needs one. Chapter 9
TLS and HTTPS: Transport Layer Security encrypts data between two programs and, through certificates, proves the server's identity. HTTPS is HTTP carried over TLS. Chapter 0
TOGAF: The Open Group Architecture Framework, a widely used framework and method for enterprise architecture published by The Open Group; its current version is the TOGAF Standard, 10th Edition (2022). Chapter 1
Token: The unit of text a language model reads and writes: a word or piece of a word from a fixed vocabulary. Limits, prices and speed are all counted in tokens. Chapter 12
Token bucket: A rate-limiting algorithm in which tokens are added to a bucket at a fixed rate up to a capacity, and each request spends a token; it allows bursts up to the capacity and a steady average rate. Chapter 9
Tokenisation: Replacing a sensitive value such as a card number with a meaningless token, while the real value is kept in a separate, tightly protected vault, often run by a payment provider. Chapter 8
Tolerant reader: A consumer that reads only the fields it needs and ignores anything it does not recognise, so that providers can add fields without breaking it. Chapter 7
Tool calling: A model capability in which the model returns a structured request to call a function the application has described; the application, not the model, executes it. Chapter 12
Trace sampling: Keeping only some traces to control cost: head-based sampling decides when a request starts, tail-based sampling decides after it ends, so it can keep slow and failed requests. Chapter 9
Trade-off: A choice in which gaining one benefit means accepting a cost or giving up another benefit, such as faster delivery at the price of higher running cost. Chapter 1
Trade-off point: An architectural decision that affects more than one quality attribute, improving one while harming another. Chapter 2
Transaction: A group of database operations treated as one unit: either all of them take effect (commit) or none do (rollback). Chapter 0
Transactional outbox: A pattern in which a service writes outgoing messages to an outbox table in the same local transaction as its business change; a relay later publishes them, giving at-least-once delivery without a distributed transaction. Chapter 6
Transformer: The neural network design introduced by Vaswani and colleagues in 2017, built on self-attention, which underlies today's large language models and most embedding models. Chapter 12
Transitional architecture: Temporary software, such as routing layers, adapters and synchronisation jobs, built only to let old and new systems coexist during a migration and removed when it is complete. Chapter 11
Transitive dependency: A package your software uses indirectly because one of your dependencies, or one of theirs, depends on it. Chapter 8
Trunk-based development: A way of working in which developers integrate small changes into one shared main branch at least daily, instead of keeping long-lived feature branches. Chapter 10
Trust boundary: A line in a system where data or control passes between parts with different levels of trust or privilege, such as from the internet into an API, so input must be checked there. Chapter 8
Tuple space: A shared associative memory into which processes write tuples and from which they read or take matching tuples, without knowing about each other. Introduced by David Gelernter's Linda language (1985). Chapter 6
Twelve-factor app: A methodology of twelve practices for building deployable, scalable web applications, written by Adam Wiggins at Heroku in 2011 and open-sourced in 2024. Chapter 10
Two-phase commit (2PC): A protocol that makes several participants commit or abort together: a coordinator first asks all to prepare and vote, then tells all the outcome. Participants that voted yes block if the coordinator fails. Chapter 6

U

Ubiquitous language: A vocabulary shared by developers and domain experts and used consistently in conversation, documents, tests and code within one bounded context. Chapter 5
UDP: User Datagram Protocol: sends individual packets with no guarantee of delivery or order. Faster and simpler than TCP; used for video calls, games and DNS. Chapter 0
Unified Modeling Language (UML): A general-purpose graphical modelling language standardised by the Object Management Group. The current version is 2.5.1 (2017). Chapter 4
Unit cost: The cost of running a system divided by a unit of useful work, such as cost per order or per active user, so efficiency can be tracked as the business grows. Chapter 2
Unit economics: Expressing cost (and revenue) per unit of business value, such as cost per order or per active customer, so that efficiency can be judged independently of growth. Chapter 10
Unit test: An automated test that checks one small piece of code, such as a function, in isolation, and runs in milliseconds. Chapter 0
Universal Scalability Law (USL): Neil Gunther's model of how capacity grows with added nodes, accounting for contention for shared resources and the cost of keeping data coherent. It predicts a peak beyond which adding nodes reduces capacity. Chapter 2
Unsupervised learning: Machine learning without labels, in which the model finds structure on its own, such as clusters of similar customers or unusual transactions. Chapter 12
Upcasting: Converting an event stored in an old schema version into the current version as it is read, so that application code only has to handle one shape. Chapter 7
USE method: Brendan Gregg's checklist for analysing resources: for every resource, check Utilisation, Saturation and Errors. Chapter 9
User story: A short description of a feature from the point of view of the person who wants it, often written as: As a [role], I want [capability], so that [benefit]. Chapter 0
UTF-8: The dominant way of encoding text as bytes. It can represent every Unicode character, using one byte for basic English letters and up to four bytes for others. Chapter 0
Utilisation: The fraction of time a resource is busy, usually written ρ (rho). A server handling 40 requests a second that each need 20 ms of work is 80% utilised. Chapter 2
Utility tree: A tree, from the ATAM, that refines overall utility into quality attributes and then concrete scenarios, each rated by business importance and technical difficulty. Chapter 2

V

Value object: A domain object defined only by its values, with no identity of its own, and usually immutable, such as an amount of money or an address. Chapter 5
Vector database: A store for embeddings (lists of numbers representing meaning) that finds the items most similar to a query, usually with approximate nearest-neighbour indexes. Chapter 7
Version control: A system that records every change to a set of files, who made it and why, so that people can work in parallel, review changes and return to any earlier version. Chapter 0
View: A representation of one or more structures of a system, aimed at particular concerns of particular stakeholders, such as a deployment diagram for operations staff. Chapter 1
View component: In ISO/IEC/IEEE 42010:2022, one part of a view, such as a diagram, table or model, governed by a model kind. The 2011 edition called it an architecture model. Chapter 4
Viewpoint: A specification of how to build and read one kind of architecture view: which stakeholders and concerns it serves and which modelling conventions it uses. Chapter 1
Virtual machine (VM): A software imitation of a complete computer, with its own operating system, running alongside other VMs on one physical machine under a hypervisor. Chapter 0
Virtual user: A simulated user in a load-testing tool that runs a script of requests, usually in a loop. Chapter 9

W

Walking skeleton: A tiny implementation of the system that performs a small end-to-end function through all the main architectural components, usually built first. Chapter 1
Warm standby: A disaster recovery strategy that keeps a scaled-down but fully working copy of the system running in a second region, ready to take traffic and scale up. Chapter 10
Watermark: A stream processor's moving estimate that all events up to a certain event time have probably arrived, used to decide when a window's result can be emitted. Chapter 7
WCAG: The Web Content Accessibility Guidelines from the W3C. Version 2.2 (2023) sets testable success criteria at levels A, AA and AAA; level AA is the usual legal benchmark. Chapter 2
Web API: An API offered over a network, usually using HTTP, so that programs on different machines, written in different languages, can work together. Chapter 0
Webhook: An HTTP request that a provider sends to a URL registered by its customer when an event happens, such as a payment succeeding. It reverses the usual direction of an API call. Chapter 0
Weighted decision matrix: A table that scores each option against weighted criteria so that the reasoning behind a choice is explicit and open to challenge. Chapter 1
Wide-column store: A NoSQL database that groups data into rows identified by a key, each with many columns, spread across many machines. Designed for very large write volumes. Chapter 0
Workload identity: A verifiable identity for a running service rather than a person, issued by the platform (for example a SPIFFE ID in a short-lived certificate), used instead of shared secrets. Chapter 8
Write skew: An anomaly in which two transactions read overlapping data, each decides a change is safe, and they update different rows, together breaking a rule each one checked. Chapter 7
Write-ahead log (WAL): An append-only log on disk in which a database records each change before applying it, so that committed work survives a crash; replicas are often fed from it. Chapter 7
Write-behind cache: A caching pattern in which writes are acknowledged once they reach the cache and are written to the underlying store later, in the background; also called write-back. Chapter 7
Write-through cache: A caching pattern in which every write goes to the cache and to the underlying store before it is acknowledged, so the cache is never older than the store. Chapter 7

X

X-as-a-Service: An interaction mode in which one team consumes something another team provides, through a clear, documented interface and with little day-to-day collaboration. Chapter 11
XA: The X/Open standard (1991) interface between a transaction manager and resource managers such as databases and message brokers, used to run two-phase commit across them. Chapter 6

Y

Y-statement: A one-sentence decision record by Olaf Zimmermann: in the context of, facing, we decided for, and neglected, to achieve, accepting that. Chapter 4
YAGNI: You aren't gonna need it: an Extreme Programming practice of not building capabilities for needs that are only presumed, because they cost effort now and complexity later. Chapter 3

Z

Zero trust: A security model that grants no implicit trust based on network location: every request is authenticated, authorised and encrypted, per resource and per session (NIST SP 800-207). Chapter 8