Software & Application Architecture Glossary
A single reference for the acronyms and terms introduced across this section — link here instead of re-deriving a definition from an earlier page.
| Term | Meaning | Defined in |
|---|---|---|
| Module | A cohesive, independently understandable unit of code with one clear responsibility | Modular Design & Decomposition |
| Single Responsibility Principle | A module should have only one reason to change | Modular Design & Decomposition |
| God module/class | A module that has accumulated too many unrelated responsibilities | Modular Design & Decomposition |
| Bounded context | A boundary within which a term/concept has one consistent meaning | Service & Component Boundaries |
| Coupling | How much one component depends on another’s internals | Service & Component Boundaries |
| Cohesion | How closely related the things inside one boundary are | Service & Component Boundaries |
| Conway’s Law | System structure tends to mirror the organization’s communication structure | Service & Component Boundaries |
| Contract | The agreed request/response shape a consumer can rely on | API Design & Contracts |
| Breaking change | A contract change that would fail an existing consumer | API Design & Contracts |
| Deprecation window | The communicated period during which an old version stays live before removal | API Design & Contracts |
| Event | A record that something happened, published without expecting an immediate reply | Event-Driven & Asynchronous Communication |
| Pub/sub | A pattern where producers publish and any number of subscribers receive independently | Event-Driven & Asynchronous Communication |
| Idempotent consumer | A consumer that produces the same result even if it processes the same event twice | Event-Driven & Asynchronous Communication |
| Dead-letter queue | Where messages go after repeated processing failures, for inspection instead of silent loss | Event-Driven & Asynchronous Communication |
| Hexagonal / ports & adapters | Business logic depends on interfaces (“ports”); technology-specific code plugs in as “adapters” | Architectural Styles & Design Patterns |
| Microservices | Independently deployable services, each owning its own data and scaling | Architectural Styles & Design Patterns |
| CQRS | Separating the read model from the write model | Architectural Styles & Design Patterns |
| Scale up / scale out | Growing a single instance’s resources vs. adding more instances to share load | Performance & Scalability Engineering |
| Stateless service | A service that keeps no request-specific state between calls, so any instance can handle any request | Performance & Scalability Engineering |
| Cache invalidation | Deciding when cached data is no longer valid and must be refreshed | Performance & Scalability Engineering |
| Performance budget | A target metric (e.g. p95 latency) set before implementation, not after | Performance & Scalability Engineering |
| Authentication | Confirming who is making the request | Security by Design |
| Authorization | Confirming what the authenticated caller is allowed to do | Security by Design |
| Least privilege | Granting only the minimum access needed to perform a task | Security by Design |
| Allow-list validation | Accepting only explicitly known-good input, rejecting everything else | Security by Design |
| Circuit breaker | A control that stops calling a failing dependency after repeated failures, failing fast instead | Resilience & Observability |
| Graceful degradation | Returning a reduced but still useful response instead of a hard failure | Resilience & Observability |
| Backoff | Increasing the delay between retries to avoid overwhelming a struggling dependency | Resilience & Observability |
| Observability | The ability to understand a system’s internal state from its external outputs (logs, metrics, traces) | Resilience & Observability |
| Richardson Maturity Model | A 4-level scale (0-3) rating how RESTful an API is | API Design & Contracts |
| C4 model | Four diagramming levels (Context, Container, Component, Code) for structure at the right zoom level | Service & Component Boundaries |
| Twelve-Factor App | Named conventions for building horizontally scalable, stateless services | Performance & Scalability Engineering |
| Bicep | Azure’s declarative infrastructure-as-code language | Performance & Scalability Engineering |
| Autoscale rule | An Azure Monitor rule that changes instance count based on a metric threshold | Performance & Scalability Engineering |
| RU/s | Request Units per second — Azure Cosmos DB’s elastic throughput scaling unit | Performance & Scalability Engineering |
| Read replica | A read-only, kept-in-sync copy of a database used to scale out read traffic | Performance & Scalability Engineering |
| Paired region | An Azure region paired with another for sequenced updates and physical isolation | Resilience & Observability |
| Application Insights | Azure’s application performance monitoring service, capturing traces, dependency calls, and metrics | Resilience & Observability |
| Azure Function | A serverless (FaaS) compute unit that runs in response to a trigger | Event-Driven & Asynchronous Communication |
| Azure Storage Account | Azure’s managed storage service for blobs, queues, tables, and files | Event-Driven & Asynchronous Communication |
| Serverless (FaaS) | Function-as-a-Service: code that runs on demand, with the platform managing scaling and infrastructure | Architectural Styles & Design Patterns |
| Polyglot persistence | Choosing a different data store technology per bounded context based on its own needs | Service & Component Boundaries |
Related pages
Section titled “Related pages”Part of Introduction to Software & Application Architecture.