Terminology

2225 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 areas2225 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 Architecture74 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 Architecture69 Streaming & Real-Time Data69 Data Governance & Semantics74 Frontend & Experience Architecture66 Edge, Mobile & IoT68 Regulatory & Data Protection Architecture65 Assurance, Audit & Model Risk69

Kind Any concept801 practice736 pattern377 metric127 case-study77 tool62 protocol45

4 terms shown.

Term	Kind	Topic	What it is
Cluster Multi-Tenancy Soft Multi-Tenancy, Namespace Tenancy	concept	Platform Tenancy	Multiple teams or workloads sharing one cluster, isolated by namespaces, quotas and policy rather than by separate infrastructure.
Namespace Tenancy	pattern	Platform Tenancy	Isolating teams within a shared cluster by namespace plus quota plus network policy, and being explicit about what that does not isolate.
Noisy Neighbour Resource Contention, Co-Tenant Interference, Shared-Fate Degradation	concept	Platform Tenancy	One workload degrading others by consuming a shared resource - and specifically the resources nobody set limits on, such as control-plane capacity, node network bandwidth and local disk.
Object Count Quota Resource Count Limit, Control-Plane Quota	practice	Platform Tenancy	A per-tenant limit on how many control-plane objects a team may create, which is the control that prevents one team's design choice from exhausting the shared configuration store every other team depends on.