Advanced Business Tech #scalability #architecture #due-diligence #load-testing

Scalability Risk Assessment

5 exercises — master scalability risk vocabulary for TDD: horizontal vs vertical scaling, stateful vs stateless services, SPOF identification and communication, bottleneck analysis (N+1 query, connection pool exhaustion, synchronous pipeline), load testing vocabulary (RPS, P99 latency, error rate, soak test), and scalability architecture language (cache hit rate, CDN offload, read replica).

0 / 5 completed

Scalability risk quick reference

Scalability ceiling: the load at which architecture fails without redesign. Key probe: "What breaks first at 10x load?"
Horizontal scaling: add more instances (requires stateless services). Vertical scaling: add more resources to existing (hard ceiling, not elastic).
SPOF: any component without redundancy whose failure = total outage. Trace every critical path and ask "if this fails, what happens?"
Bottleneck types: N+1 query (loop with DB call inside), connection pool exhaustion, synchronous pipeline, missing index, I/O-bound vs CPU-bound.
Load test vocabulary: RPS (load unit), P99 latency (tail latency), error rate (% 5xx under load). No load tests = unquantified ceiling = risk finding.
Architecture quality signals: stateless services ✓, high cache hit rate ✓, CDN offload ✓, read replicas ✓, async queue pattern ✓.

1 / 5

A VC partner asks the TDD team: "The company currently has 50,000 active users. Post-acquisition, our growth model projects 500,000 within 18 months. Before we sign, I need to know: can this platform handle that?"

The TDD lead replies: "That's exactly the right question. Let me walk you through how we frame scalability risk, and what the architecture tells us about their ceiling."

How do you define and frame scalability risk in a technical due diligence context?

Framing scalability as a risk with a concrete ceiling is the key communication skill here. "The platform cannot scale beyond 80,000 concurrent users without a database architecture change — estimated 4 months and $150K to implement" gives an investor a specific risk with a specific cost and timeline attached.

Scalability dimension assessment:

Dimension	Healthy indicator	Risk indicator
Application tier	Stateless; horizontally auto-scalable (Kubernetes/ECS)	Stateful; sticky sessions; manual scaling only
Database tier	Read replicas; connection pooling; or managed cloud DB	Single primary DB, no replicas, high connection usage
Caching	Redis/Memcached layer; high cache hit rate (>80%)	No caching layer; all reads hit primary DB directly
CDN / static	Static assets served via CDN; origin shielded	All static assets served from application servers
Load test evidence	Recent load tests at 2–5x current peak documented	No load tests exist; ceiling unknown

Scalability risk framing phrases:
• "The application tier is stateless and auto-scales via Kubernetes. The scalability risk is concentrated entirely in the database layer — a single PostgreSQL primary with no read replicas and a connection pool of 150."
• "The current architecture has a proven ceiling of approximately 10,000 concurrent users. Beyond that point, the primary database connection pool exhausts and the application returns errors. This is addressable in infrastructure, but requires 6–8 weeks of work."

Key vocabulary:
• Horizontal scaling (scale out) — adding more instances of a service to distribute load; requires stateless architecture; elastic, cost-proportional
• Vertical scaling (scale up) — adding more compute resources (CPU/RAM) to existing instances; limited by hardware ceiling; non-elastic
• Scalability ceiling — the load threshold at which the current architecture fails or requires architectural redesign (not just more hardware); the key TDD metric for investment risk
• Shared state bottleneck — a resource (database, cache, queue) that all application instances must access; because it cannot be easily replicated, it constrains horizontal scaling

2 / 5

During the architecture review, the TDD engineer draws a system diagram on a whiteboard and begins circling specific components. She marks two with a red SPOF label and explains to the investment analyst observing: "These are your single points of failure. Both of these, if they go offline for any reason, take everything down with them. That's not an architecture decision — that's a risk that needs to be priced."

What is a single point of failure and how do TDD assessors identify and communicate SPOF risk?

SPOF analysis converts abstract architecture concerns into financial risk language. Every SPOF has a calculable expected annual downtime cost: you can divide by 8,760 hours to get hourly impact and multiply by expected SPOF failure hours. That gives investors a number to work with.

Common SPOF patterns in SaaS architecture TDD:

SPOF pattern	Failure scenario	Mitigation vocabulary
Single DB primary	DB failure = total outage; no reads, no writes	"Implement RDS Multi-AZ with automatic failover"
Single 3rd-party API	External service outage = core function unavailable	"Dual-provider with circuit breaker pattern"
Single region deployment	Cloud region outage = complete service unavailability	"Multi-region active-active or active-passive failover"
Single load balancer	LB failure = all traffic dropped	"Managed LB service or active-standby pair"

SPOF communication language:
• "I've identified three SPOFs in the architecture. Two are straightforwardly addressable through infrastructure changes in 2–3 weeks. The third — the single-region deployment — requires a more significant infrastructure investment to resolve."
• "Our biggest concern is the SPOF in the authentication service. A single Redis instance holds all active user sessions. If it fails, every user is logged out simultaneously and cannot log back in until the instance recovers. This is high-probability in a growth scenario where Redis is being pushed to its memory limits."

Key vocabulary:
• Single point of failure (SPOF) — a component with no redundancy whose failure causes total or critical-path system outage; identified by tracing every critical request path and asking "what if this fails?"
• Circuit breaker pattern — a resilience pattern that detects when a downstream dependency is failing and stops sending it requests, preventing cascading failure; the standard SPOF mitigation for external API dependencies
• Multi-AZ deployment — deploying application and database tiers across multiple cloud availability zones, eliminating single data-centre failure as a SPOF

3 / 5

The TDD engineer is doing a deep-dive performance review and identifies the following in the codebase: "Every API endpoint loads the user's entire permission set from the main database on each request. And this permissions table has 2.3 million rows with no index. At current traffic, you see 400ms average response. At 3x traffic, you'll be looking at 2,000ms — if the DB doesn't time out first."

This is an example of bottleneck analysis. What vocabulary do TDD assessors use to identify and communicate system bottlenecks?

The N+1 query problem is one of the most common bottlenecks found in startup codebases — it's easy to introduce accidentally and invisible at low data volumes, but catastrophic at scale. Being able to name it precisely ("I found an N+1 pattern in your order loading logic") shows technical credibility in a TDD context.

Bottleneck vocabulary with TDD report language:

Bottleneck type	Technical signature	TDD report phrasing
N+1 query	Loop with DB call inside; 1 query per item	"Orders endpoint fires 1 query per order line item — at 500 items, that's 501 DB calls per request"
Connection pool exhaustion	Max pool connections hit; new requests queue or fail	"Current pool size of 100 will be exhausted at projected 3x load — recommend PgBouncer or pool resize"
Synchronous pipeline	User request blocks on slow downstream call	"Email sending is synchronous in the checkout flow — a slow SMTP server directly causes checkout timeouts"
Missing index	Full table scan on large table; latency scales with data	"No index on user_id in the audit_log table — at 2.3M rows, this produces sequential scans of 400–800ms per lookup"

Bottleneck interview questions used in TDD:
• "Can you show me your slowest database query in production? What does it do?"
• "What happens to your application when your primary database is under heavy write load?"
• "Are there any operations in the checkout or core transaction path that call external services synchronously?"

Key vocabulary:
• N+1 query problem — a code antipattern where loading N records triggers N additional database queries (one per record) instead of a single batched query; linear performance degradation with data volume
• Connection pool exhaustion — a failure mode where all database connections are in use, new requests are queued or rejected; happens at sustained peak load if pool size is insufficient or queries are slow to release connections
• I/O-bound bottleneck — performance constrained by waiting for external I/O (network, database, disk, API); addressable with async patterns, caching, queueing
• CPU-bound bottleneck — performance constrained by compute; requires algorithmic optimisation or horizontal scaling

4 / 5

The TDD team asks the engineering team: "Can you provide your latest load test results?" The target company CTO responds: "We've never run a formal load test. We have monitoring in production and we haven't had any outages."

The TDD lead responds: "No load test evidence is itself a finding. We can't model your scalability ceiling without data. Let me explain what we'd need to see and what this tells us about your risk profile."

How do you discuss load testing in a TDD context, and what makes an absence of load testing a risk finding?

The "no load tests" finding translates directly into deal language: "We cannot confirm that this architecture supports the growth model presented in the investment memorandum. We recommend a load testing programme as a condition precedent to close, or a $100K infrastructure risk buffer added to the deal model." Never leave an unquantified risk sitting in a TDD report.

Load test vocabulary for TDD context:

Term	Definition	TDD application
RPS	Requests per second — standard load measurement unit	"Current peak is ~200 RPS; growth model requires 2,000 RPS within 18 months"
P99 latency	99th percentile response time under load; the "tail latency"	"P99 exceeds 2,000ms at 500 RPS — users experience timeouts at moderate load"
Error rate	% of requests returning errors (4xx/5xx) during load test	"Error rate climbs above 5% at 800 RPS — this is the effective ceiling"
Ramp test	Gradually increase load to identify the failure point	Used to determine exact RPS ceiling; required as part of pre-close recommendation
Soak test	Sustained load for extended period (hours) to detect memory leaks, drift	Identifies resource leaks not visible in short-duration tests

TDD language for the "no load test" finding:
• "We have no empirical data on this system's scalability ceiling. The investment thesis depends on 10x user growth in 18 months — but we cannot confirm architecture can support that without load testing. Recommend load test programme as condition precedent or explicit infrastructure buffer in the model."

Key vocabulary:
• RPS (requests per second) — the primary unit of load in web application testing; the target RPS is derived from the growth model
• P99 latency — the response time at the 99th percentile; degradation of P99 under load reveals the system's approach to its ceiling
• Scalability ceiling — the RPS or concurrent user load at which the system begins to fail; defined by the first metric to breach its threshold (error rate, P99 latency, resource exhaustion)

5 / 5

Having completed the scalability assessment, the TDD engineer prepares the architecture section of the TDD report. She begins: "The good news is the application tier is genuinely well-designed. The team understood stateless service design, cache hit rate, and CDN offload. The scalability risk is concentrated and quantifiable — and more importantly, it's addressable."

What architecture vocabulary is used to describe scalability design quality in a TDD assessment?

Good scalability architecture vocabulary allows you to precisely communicate where the design is strong and where it is weak. "The application tier is stateless and horizontally scalable — the database tier is the constraint" is far more useful than "the system might not scale."

Scalability architecture vocabulary summary:

Term	What it indicates	TDD report usage
Stateless services	Horizontally scalable; any instance handles any request	"Application tier is stateless — no scaling constraint at this layer"
Cache hit rate	% of reads served from cache vs DB; reduces DB pressure	"Redis cache hit rate of 87% — database is well-protected from read load"
CDN offload	% of total traffic served from edge; protects origin	"72% of all traffic is CDN-served — origin receives only dynamic requests"
Read replica	Database replica for read traffic; divides read load	"2 read replicas in place; analytics queries routed to replica — primary is write-only in practice"
Async queue pattern	Non-blocking work offloaded from request path via queue	"Email, reporting, and payment webhook processing are all async — no synchronous pipeline bottlenecks on checkout"

Scalability assessment summary language:
• "The application-level scalability is strong. Services are stateless, deployed via Kubernetes with auto-scaling, and the CDN offloads 68% of requests. The constraint is at the database layer: the primary has one read replica, no sharding, and connection pooling configured for current load only. This single database is the scalability ceiling and must be addressed before the growth phase."

Key vocabulary:
• Stateless service — a service that holds no user-specific session state; each request is self-contained; enables trivial horizontal scaling
• Cache hit rate — the proportion of read requests answered from cache without reaching the database; a critical indicator of database load protection
• CDN offload ratio — the proportion of all traffic served by CDN edge nodes rather than origin servers; high offload = origin protected from traffic volume spikes
• Read replica — a synchronised read-only copy of the primary database; separates read load from write load to protect primary database throughput