Glossary of Scalability & Architecture Terms

A

Active-Active Architecture: A deployment pattern where two or more sites/instances handle live traffic simultaneously, rather than one sitting idle as a backup. Improves both availability and capacity, but requires careful data consistency design.
Active-Passive Architecture: A deployment pattern where a standby site or instance stays idle until the primary fails, then takes over. Simpler to reason about than active-active, but wastes capacity and can be slower to fail over.
API Gateway: A single entry point that routes, authenticates, and rate-limits requests to backend services — common in architectures split along the AKF Scale Cube's Y-axis (functional decomposition).
Auto Scaling: Automatically adding or removing compute capacity in response to load, typically along the X-axis of the AKF Scale Cube (horizontal duplication).
Availability: The percentage of time a system is operational and able to serve requests, usually expressed in "nines" (e.g. 99.9%, 99.99%). Core to AKF's Availability Risk Model and technical due diligence assessments.

B

Backpressure: A signal from a downstream system telling upstream callers to slow down, preventing an overloaded component from being overwhelmed further and cascading into a wider failure.
Blast Radius: The scope of impact when a component fails — how many users, services, or transactions are affected. Reducing blast radius through fault isolation is a recurring theme in AKF's architecture reviews.
Blue-Green Deployment: Running two identical production environments ("blue" and "green"), where traffic is switched from the old version to the new one instantly, enabling fast rollback if something breaks.
Bulkhead Pattern: Partitioning a system into isolated pools of resources (connections, threads, capacity) so that exhaustion in one pool doesn't starve the rest of the system — a practical implementation of fault isolation.

C

Cache Invalidation: The process of removing or updating stale data in a cache once the underlying source changes. Famously one of the hardest problems in computer science to get right at scale.
Caching: Storing a copy of frequently-accessed data closer to where it's needed (in memory, at the edge, etc.) to reduce latency and load on primary data stores.
Canary Deployment: Releasing a new version to a small subset of traffic first, monitoring for problems, then gradually rolling out to everyone — limits blast radius if the release has a defect.
CAP Theorem: A principle stating that a distributed data store can only guarantee two of three properties at once: Consistency, Availability, and Partition tolerance. Understanding this tradeoff is fundamental to Z-axis (data partitioning) design decisions.
Capacity Planning: Forecasting the compute, storage, and network resources a system will need to handle expected (and unexpected) growth, a standard part of AKF's technical due diligence process.
CDN (Content Delivery Network): A geographically distributed network of servers that caches and serves content close to end users, reducing latency and offloading traffic from origin servers.
Chaos Engineering: Deliberately injecting failures into a production or production-like system to test whether fault isolation and recovery mechanisms actually work as designed, rather than assuming they do.
Circuit Breaker: A pattern that stops calling a failing downstream service after repeated errors, giving it time to recover instead of piling on more requests — a common building block of fault isolation.

D

Data Consistency: The guarantee that all reads of a piece of data reflect the same value across a distributed system, at least eventually. Strong vs. eventual consistency is a core architecture tradeoff at scale.
Database Sharding: Splitting a database horizontally across multiple physical instances, each holding a subset of the data — the practical implementation of Z-axis (data partitioning) scaling.
Disaster Recovery (DR): The plan and infrastructure for restoring service after a catastrophic failure (data center loss, major outage), typically measured by Recovery Time Objective and Recovery Point Objective.

E

Eventual Consistency: A consistency model where, given enough time without new updates, all replicas of data will converge to the same value — trading immediate consistency for higher availability and lower latency.

F

Failover: The automatic or manual process of switching to a redundant system when the primary one fails.
Fault Isolation: Separating a system into independent zones so that a failure in one zone can't cascade into a total outage. One of the five pillars of the AKF Scalability Framework — see the Framework page for detail.
Fault Isolation Zone (Swim Lane): A self-contained slice of a system — often aligned to a customer segment, feature, or geography — that can fail independently without taking down the rest of the platform.

G

Graceful Degradation: Designing a system so that when part of it fails, the user experience is reduced (e.g. recommendations disappear) rather than the whole application going down.

H

High Availability (HA): System design intended to keep a service operational for a very high percentage of time, typically through redundancy, failover, and fault isolation.
Horizontal Scaling: Adding more machines/instances to handle load, rather than making a single machine bigger. Corresponds to the X-axis of the AKF Scale Cube.

I

Idempotency: A property of an operation where performing it multiple times has the same effect as performing it once — critical for safely retrying failed requests in distributed systems.

L

Latency: The time it takes for a request to receive a response, usually measured in milliseconds. A key metric in AKF's V Delivery Model monitoring and telemetry work.
Load Balancing: Distributing incoming traffic across multiple servers or instances so no single one becomes a bottleneck — the mechanism that makes X-axis (horizontal) scaling work.
Load Testing: Simulating expected (or peak) traffic against a system to verify it performs acceptably before real users hit it — part of AKF's Automated Test Systems pillar in the V Delivery Model.

M

Master-Slave Replication (Leader-Follower): A data replication pattern where one node (the leader/master) accepts writes and one or more followers/slaves replicate that data for reads or failover.
Microservices: An architectural style that splits an application into small, independently deployable services organized around business capabilities — a common expression of Y-axis (functional) decomposition.
Monolith: An application built and deployed as a single, unified unit. Not inherently bad — many successful companies run monoliths — but scaling one requires different strategies than scaling decomposed services.
Multi-Region Architecture: Deploying a system across multiple geographic regions for lower latency to global users and resilience against a region-wide outage.

N

N+1 Redundancy: A capacity planning principle: provision enough extra capacity ("+1" or more) to survive the loss of at least one unit (server, data center, region) without service degradation.

O

Orchestration: Automated management of containerized or distributed services — deployment, scaling, networking, and health checks — often via tools like Kubernetes. Central to the Production Automation & Orchestration pillar of AKF's V Delivery Model.

P

Podding: Grouping a customer, tenant, or dataset with all the infrastructure it needs into a self-contained unit ("pod"), so pods can be scaled and isolated independently — a common Z-axis pattern.

R

Read Replica: A copy of a database used to serve read queries, offloading traffic from the primary write instance and improving read scalability.
Recovery Point Objective (RPO): The maximum acceptable amount of data loss, measured in time, after a failure — e.g. an RPO of 1 hour means you can tolerate losing up to an hour of data.
Recovery Time Objective (RTO): The maximum acceptable time to restore service after a failure.
Rolling Deployment: Gradually replacing old instances of a service with new ones, a few at a time, so the application stays available throughout the release.

S

Scalability: A system's ability to handle increasing load — more users, data, or transactions — without a proportional increase in cost or degradation in performance. The subject of AKF's founding books, The Art of Scalability and Scalability Rules.
Service Level Agreement (SLA): A formal, often contractual, commitment about a service's performance or availability — e.g. "99.9% uptime" — usually with defined consequences if it's not met.
Service Level Indicator (SLI): A specific, measured metric (e.g. request latency, error rate) used to evaluate whether a service is meeting its objectives.
Service Level Objective (SLO): An internal target for a Service Level Indicator (e.g. "99.95% of requests under 200ms") that a team aims to meet, typically stricter than the external SLA.
Sharding Key: The attribute (customer ID, region, etc.) used to decide which shard a given piece of data belongs to in a Z-axis (data partitioning) design. Choosing the wrong sharding key is one of the most common architecture mistakes we see in technical due diligence.
Single Point of Failure (SPOF): Any component whose failure would take down the entire system. Identifying and eliminating SPOFs through fault isolation and redundancy is a core part of AKF's Availability Risk Model.
Stateless Architecture: A design where individual servers don't retain session/user data between requests, so any instance can handle any request — a prerequisite for easy horizontal (X-axis) scaling.
Stress Testing: Pushing a system beyond its expected peak load to find its actual breaking point and understand how it fails, rather than just whether it meets expected load.
Swimlaning: The practice of building fault isolation zones ("swim lanes") into an architecture, typically along customer, geography, or feature boundaries.

T

Technical Debt: The accumulated cost of past shortcuts or deferred fixes in a codebase or architecture, which slows future development until addressed.
Technical Due Diligence: A comprehensive evaluation of a company's architecture, engineering organization, and process — commonly performed ahead of an investment or acquisition. See AKF's own Technical Due Diligence service for how we run this.
Throttling: Deliberately limiting the rate of requests a client or service can make, to protect downstream systems from being overwhelmed.
Throughput: The number of requests or transactions a system can process in a given time period — often the metric that matters most when evaluating whether horizontal scaling is working.

U

Uptime: The amount of time a system has been operational and available, often expressed as a percentage over a given period — the everyday term for availability.

V

Vertical Scaling: Increasing the resources (CPU, memory) of a single machine rather than adding more machines. Simpler than horizontal scaling but has a hard ceiling and doesn't improve fault tolerance.

X

X-Axis Scaling: The first axis of the AKF Scale Cube: horizontal duplication — cloning identical instances of code and data behind a load balancer to handle more traffic.

Y

Y-Axis Scaling: The second axis of the AKF Scale Cube: functional decomposition — splitting a system by service, function, or business capability so components scale and fail independently.

Z

Z-Axis Scaling: The third axis of the AKF Scale Cube: data partitioning — splitting data by customer, geography, or another lookup value (sharding) so no single data store becomes a bottleneck.

Glossary of Scalability & Architecture Terms.

A

B

C

D

E

F

G

H

I

L

M

N

O

P

R

S

T

U

V

X

Y

Z

Ready to Scale Your Technology?