Terminology
2205 terms, tools, patterns and metrics an architect is expected to use precisely. Each one gets a short explanation of what it is, and — where it matters — what it is commonly confused with. Search filters as you type; the column headers sort.
All areas2205
Architecture Fundamentals77
Distributed Systems107
Data Architecture110
Cloud Architecture94
Networking88
API & Integration Architecture82
Reliability & Resilience75
Observability70
Performance & Capacity Engineering72
Security Architecture86
Cost Architecture & FinOps71
Business Architecture67
Architecture Communication67
Enterprise Architecture66
Legacy Modernization71
AI-Era Architecture69
Software Architecture & Engineering71
Architecture Patterns71
Architecture Decision-Making63
The Architect's Meta-Skills61
Delivery & Release Engineering66
Platform Engineering & Developer Experience70
Testing & Quality Architecture66
Data Platform Architecture64
Streaming & Real-Time Data69
Data Governance & Semantics69
Frontend & Experience Architecture66
Edge, Mobile & IoT68
Regulatory & Data Protection Architecture65
Assurance, Audit & Model Risk64
2205 terms shown.
| Term | Kind | Topic | What it is |
|---|---|---|---|
| Graceful Degradation in Practice | pattern | Graceful Degradation | Deliberately reducing functionality to preserve the core when a dependency fails — a product decision expressed in architecture. |
| Graduated Escape Hatch Partial Opt-Out, Layered Override | pattern | Abstraction Level Choice | The ability to override one component of a platform's abstraction without abandoning the rest - which prevents a single unmet requirement from causing total defection. |
| Grain Declaration | practice | Dimensional Modelling | Stating exactly what one row of a fact table represents, before any column is chosen, because every later decision depends on it. |
| Graph Database | tool | NoSQL Stores | A store whose first-class citizens are nodes and the relationships between them, making multi-hop traversal cheap. |
| GraphQL | protocol | API & Integration | A query language and runtime where the client specifies exactly which fields it needs, against a typed schema, usually via a single endpoint. |
| GraphQL N+1 Problem DataLoader Pattern | concept | GraphQL | The query explosion that occurs when each item in a list independently resolves its nested fields, turning one request into hundreds of database calls. |
| Gray Failure Partial Failure, Fail-Slow | concept | Failure Modes | A component that is degraded rather than down, passing health checks while serving a portion of requests slowly or incorrectly. |
| Greenfield Velocity Illusion Rewrite Head Start, Front-Loaded Rewrite Progress | concept | Rebuild vs Re-architect | The early speed advantage a from-scratch rebuild shows because it is running with all the real constraints switched off, which makes its estimate systematically wrong in the same direction every time. |
| Grey Failure Partial Failure, Fail-Slow | concept | Failure Modes | A component that is degraded rather than down — slow, intermittently erroring, or failing for a subset of operations — which defeats health checks built for binary states. |
| gRPC | protocol | API & Integration | A contract-first RPC framework using Protocol Buffers over HTTP/2, with generated clients and servers and first-class streaming. |
| gRPC API Design | practice | gRPC APIs | Designing service interfaces in a schema-first binary protocol — where the discipline differs from REST and where the mistakes are permanent. |
| gRPC as a Transport | protocol | gRPC Transport | A binary contract-first RPC protocol over HTTP/2 — efficient and strongly typed for internal service-to-service calls, awkward at the browser edge. |
| gRPC Status Codes | concept | gRPC APIs | A fixed set of codes that classify failures and tell a client whether retrying is appropriate. |
| gRPC Streaming | concept | gRPC Transport | Four call patterns — unary, server streaming, client streaming and bidirectional — built on HTTP/2 streams. |
| Guarantee Surface Promise Surface, Service Guarantee Footprint | concept | Product Thinking | The set of customer-facing promises a product has made, each of which obliges the architecture to detect its own breach and pay for it - so this surface, not the feature count, drives a whole class of build cost. |
| Guardrail | pattern | Guardrails vs Gates | A control that makes the unsafe action impossible or automatically corrected, rather than reviewing it before it happens. |
| Guardrail Availability Policy Fail-Open Guardrail Decision, Safety Check Degradation Policy | practice | Guardrails | The decision, made in advance and per action class, about what the system does when a safety check cannot run - because the alternative is that a timeout in a classifier decides your safety posture at 03:00. |
| Guardrails | pattern | Guardrails | Deterministic checks applied to model inputs and outputs, enforcing constraints that the model itself cannot be relied upon to respect. |
| Half-Open State | concept | Circuit Breakers | The circuit breaker state that allows a limited number of trial requests through to test whether a failed dependency has recovered. |
| Handling Ambiguity | practice | Handling Ambiguity | Making progress when the requirements are unclear, the stakeholders disagree, and waiting for clarity is not an option. |
| Handling Architectural Disagreement | practice | Handling Disagreement | Resolving a technical dispute in a way that produces a decision people will actually implement, rather than a winner. |
| Happy Eyeballs Connection Racing, Dual-Stack Attempt Ordering | protocol | Networking | Starting a second connection attempt on the other address family a few hundred milliseconds after the first, so a broken IPv6 or IPv4 path costs the user a short delay instead of a connection timeout. |
| Hardware Backed Credential | concept | Device Identity | A private key generated inside a secure element and unable to leave it, so device identity cannot be copied off the device. |
| Hardware Security Module HSM | tool | Key Management | A tamper-resistant device that generates and stores keys and performs cryptographic operations without the key material ever being extractable. |
| Harvest and Yield | concept | CAP & PACELC | A refinement of CAP that treats availability as a continuum — yield is the fraction of requests answered, harvest is the fraction of data reflected in an answer. |
| Head-of-Line Blocking | concept | HTTP/1.1, HTTP/2 & HTTP/3 | One delayed item stalling everything queued behind it, even when the rest could have been processed - the failure mode that ordering guarantees create. |
| Health Check | practice | Observability | An endpoint the platform polls to decide whether an instance should be restarted or should receive traffic — two different questions needing two different checks. |
| Health Check Configuration | concept | Layer 4 vs Layer 7 | The interval, timeout, and healthy/unhealthy thresholds that together determine how quickly a failed backend leaves rotation. |
| Health Check Depth Shallow vs Deep Health Check, Dependency Health Check | concept | Failover | How much of a service's dependency graph a health check consults, which determines whether the check reports an independent fault or a shared one that every instance will report at the same moment. |
| Health Check Semantics | practice | Health Checks | The distinction between liveness, readiness and startup checks, and the failure each is intended to address. |
| Health Checks | pattern | Health Checks | Endpoints that tell the platform whether to route traffic to an instance or restart it — and a well-documented way to amplify an outage. |
| Healthcare Data Protection | concept | Healthcare Data Protection | Architecture for health information — where access must be broad enough for care, auditable in detail, and safe when the system is unavailable. |
| Hedged Request Request Hedging, Tied Request | pattern | Failure Modes | Sending the same request to a second replica after a short delay and using whichever responds first, to cut tail latency caused by unlucky slow servers. |
| Hermetic Build | practice | Build Reproducibility | A build whose output is a function only of its declared inputs, so the same commit cannot produce two different artifacts. |
| Hexagonal Architecture Ports and Adapters | pattern | Architecture Patterns | Putting the domain at the centre and letting everything external — UI, database, queues — attach through ports implemented by replaceable adapters. |
| Hexagonal Architecture in Practice Ports and Adapters | pattern | Hexagonal Architecture | The application defines ports; adapters implement them — so the same core is driven by HTTP, a queue, or a test with no changes. |
| Hidden Cost Categories | concept | Total Cost of Ownership | The recurring costs routinely omitted from total-cost-of-ownership comparisons, which usually exceed the licence or infrastructure line everyone argues about. |
| Horizontal vs Vertical Scaling Scale Out vs Scale Up | concept | Performance & Capacity | Adding more machines versus making one machine bigger — and the fact that vertical is underrated for stateful tiers. |
| Hot Key Hot Partition, Hot Row, Key Skew, Celebrity Problem | concept | Partitioning & Sharding | A single key or narrow key range receiving a disproportionate share of traffic, so one partition saturates while the rest of the cluster is idle - the failure that no amount of horizontal scaling fixes. |
| Hot Key Hot Partition, Hot Shard | concept | Partitioning & Sharding | A single key or partition receiving a disproportionate share of traffic, so that a well-balanced key space still produces one overloaded node. |
| Hot Partition Hot Shard, Hot Key | concept | Partitioning & Sharding | One partition receiving disproportionate traffic, so the system saturates at a fraction of its aggregate capacity. |
| Hot, Warm and Cold Data | concept | Data Lifecycle & Retention | Classifying data by how frequently and how urgently it is accessed, so each tier can be stored on media priced for that access pattern. |
| HTTP Method Semantics | concept | REST Design | The safety, idempotency and cacheability guarantees each HTTP method carries, which clients and intermediaries rely on. |
| HTTP Protocol Versions HTTP/1.1, HTTP/2, HTTP/3, QUIC | protocol | HTTP/1.1, HTTP/2 & HTTP/3 | What each HTTP version changed, which problem it solved, and where the benefit actually shows up. |
| HTTP/2 Multiplexing | protocol | HTTP/1.1, HTTP/2 & HTTP/3 | Carrying many concurrent request/response streams over a single TCP connection, removing the need for multiple connections per origin. |
| Hub and Satellite | pattern | Data Vault Modelling | Separating stable business keys from their changing attributes and from their relationships, so each can be loaded independently and kept forever. |
| Human in the Loop HITL | pattern | AI-Era Architecture | Requiring human review or approval at a defined point in an automated flow, chosen by the reversibility and cost of the action. |
| Human in the Loop Design | pattern | Human-in-the-Loop Design | Placing human judgement at the points where automation should not decide alone — with attention to whether the human can actually exercise judgement. |
| Human-in-the-Loop Design | pattern | Human in the Loop | Placing human review at the points where model error is consequential, designed so the review is genuinely effective rather than nominal. |
| Hybrid Retrieval Dense + Sparse Retrieval, BM25 + Vector | pattern | RAG Architecture | Running lexical keyword search and dense vector search together and fusing the results, because each fails where the other succeeds. |
| Hydration | concept | Hydration Cost | The browser attaching interactivity to server-rendered HTML by re-running component logic, during which the page looks ready and is not. |
| Idempotency Idempotency Key, Exactly-Once Effect | pattern | Idempotency | The property that performing an operation twice has the same effect as performing it once — the only practical defence against the duplicates a retrying client will inevitably send. |
| Idempotency | concept | Distributed Systems | The property that performing an operation many times has the same effect as performing it once. |
| Idempotency Key | pattern | API & Integration | A client-generated unique value sent with a request so the server can recognise a retry and return the original result instead of acting twice. |
| Idempotency Key | pattern | Idempotency Keys | A client-generated identifier that lets a server recognise a retried request and return the original result instead of performing the action twice. |
| Idempotency Key Scoping Key Scope, Deduplication Scope | practice | Idempotency | The decision of what an idempotency key is unique within, what is stored alongside it, and how long it lives - the three choices that determine whether deduplication actually works. |
| Idempotency Scope | concept | Idempotency Keys | The boundary within which an idempotency key is unique and meaningful — per account, per endpoint, or global — and the retention window it lives for. |
| Idempotency Token Store | pattern | Idempotency | The durable record of which idempotency keys have been seen and what each one returned, and the component that decides whether the guarantee is real. |
| Idempotent Consumer | pattern | Exactly-Once Semantics | A message consumer whose effect is the same whether a message is processed once or many times, which is what makes at-least-once delivery safe. |
| Idempotent Pipeline | practice | ETL & ELT | A pipeline whose task can be re-run for the same input window any number of times and produce the same result. |
Nothing on this page matches. Search the whole glossary.