Non-Functional System Characteristics

Every system design interview involves trade-offs between competing goals. While functional requirements define what a system does, non-functional requirements define how well it does it. Understanding these characteristics—and how they interact—is essential for making sound architectural decisions.

This page covers the core non-functional characteristics that come up repeatedly in interviews: availability, reliability, scalability, maintainability, and fault tolerance. We'll also cover the CAP theorem, which formalizes a fundamental trade-off in distributed systems.

Availability

Availability is the percentage of time a system is operational and accessible to users. When someone says a service has "99.9% availability," they're describing how much downtime users can expect.

Measuring Availability

Availability is typically expressed as a percentage:

Availability = Uptime / (Uptime + Downtime) × 100%

The industry uses "nines" as shorthand—each additional nine dramatically reduces allowed downtime:

Factors That Affect Availability

Achieving high availability requires addressing multiple failure points:

• Redundancy — no single points of failure
• Failover mechanisms — automatic switching to healthy components
• Health monitoring — detecting failures quickly
• Geographic distribution — surviving regional outages

Calculating System Availability

When components are in series (all must work), multiply their availabilities:

System Availability = A₁ × A₂ × A₃

For three 99.9% components in series: 0.999³ = 99.7%—worse than any individual component.

When components are in parallel (any can work), the system survives if at least one works:

System Availability = 1 - (1 - A)ⁿ

For two 99% components in parallel: 1 - (1 - 0.99)² = 99.99%—much better than either alone.

Reliability

Reliability is the probability that a system performs its intended function correctly over a specified period. While availability measures uptime, reliability measures correctness during that uptime.

A system can be highly available but unreliable—it's up, but returning wrong results. Conversely, a reliable system might have availability issues if it crashes frequently (but works correctly when running).

Key Reliability Metrics

Mean Time Between Failures (MTBF) measures how long a system typically runs before failing:

MTBF = Total Operating Time / Number of Failures

Mean Time To Repair (MTTR) measures how quickly you can restore service after a failure:

MTTR = Total Downtime / Number of Failures

The goal: Maximize MTBF (fail less often) and minimize MTTR (recover faster).

Building Reliable Systems

Reliability comes from multiple layers of defense:

1. Eliminate single points of failure — replicate critical components
2. Use proven technologies — mature software has fewer bugs
3. Test thoroughly — catch issues before production
4. Design for failure — assume components will fail, handle it gracefully
5. Monitor and alert — detect issues before users do

Scalability

Scalability is a system's ability to handle increased load without degrading performance. A scalable system can grow to meet demand, whether that's more users, more data, or more transactions.

Vertical Scaling (Scale Up)

Add more resources to a single machine—more CPU, RAM, or faster storage.

Advantages:

• Simple—no code changes required
• No distributed system complexity
• Strong consistency is straightforward

Disadvantages:

• Hardware limits—you can't scale forever
• Expensive—high-end hardware costs disproportionately more
• Single point of failure

Horizontal Scaling (Scale Out)

Add more machines to distribute the load.

Advantages:

• No theoretical limit—add machines as needed
• Commodity hardware—cheaper per unit of capacity
• Built-in redundancy

Disadvantages:

• Distributed system complexity—coordination, consistency, networking
• Requires application changes—stateless design, data partitioning
• Operational overhead—more machines to manage

When to Scale

Scalability Patterns

The building blocks of scalable systems:

• Load balancing — distribute requests across servers
• Caching — reduce load on expensive operations
• Sharding — partition data across multiple databases
• Async processing — use queues to handle spikes
• Read replicas — separate read and write workloads

Maintainability

Maintainability is how easily a system can be modified, updated, and operated over time. Most of a system's cost comes after initial development—maintenance, bug fixes, and feature additions.

A maintainable system minimizes the cost and risk of change.

Three Pillars of Maintainability

1. Operability — making life easy for operations:

• Clear monitoring and alerting
• Predictable behavior under load
• Good documentation
• Easy deployment and rollback
• Self-healing capabilities

2. Simplicity — managing complexity:

• Clear abstractions hiding implementation details
• Consistent patterns throughout the codebase
• No unnecessary features or premature optimization
• Well-defined interfaces between components

3. Evolvability — adapting to change:

• Modular architecture allowing independent changes
• Backward-compatible APIs
• Feature flags for gradual rollouts
• Comprehensive testing enabling confident refactoring

Maintainability in Practice

Fault Tolerance

Fault tolerance is a system's ability to continue operating correctly when components fail. It's not about preventing failures—those are inevitable—but about ensuring failures don't cascade into system-wide outages.

Types of Failures

• Hardware failures — disk crashes, network card failures, power outages
• Software failures — bugs, memory leaks, deadlocks
• Network failures — partitions, packet loss, high latency
• Human errors — misconfigurations, bad deployments

Fault Tolerance Techniques

Replication — maintain multiple copies of data or services:

• Active-active — all replicas serve traffic
• Active-passive — standby replicas take over on failure
• Synchronous — replicas confirmed before acknowledging writes (consistency)
• Asynchronous — replicas updated in background (performance)

Checkpointing — periodically save state so you can recover:

• Database transaction logs
• Streaming job checkpoints
• Application state snapshots

Isolation — prevent failures from spreading:

• Bulkheads — separate pools for different workloads
• Circuit breakers — stop calling failing services
• Timeouts — don't wait forever for responses

Graceful degradation — offer reduced functionality instead of total failure:

• Serve cached data when backend is down
• Disable non-critical features under load
• Queue requests instead of rejecting them

The Failure Hierarchy

Build fault tolerance at multiple levels:

1. Process level — restart crashed processes
2. Machine level — failover to other machines
3. Rack/datacenter level — replicate across failure domains
4. Region level — geo-replicated for disaster recovery

CAP Theorem

The CAP theorem states that a distributed system can provide at most two of three guarantees:

• Consistency (C) — every read receives the most recent write
• Availability (A) — every request receives a response (not an error)
• Partition Tolerance (P) — the system continues operating despite network failures

Why You Can't Have All Three

Network partitions are inevitable in distributed systems. When a partition occurs, you must choose:

• Respond with potentially stale data (sacrifice Consistency for Availability)
• Wait or error until partition heals (sacrifice Availability for Consistency)

You can't choose to sacrifice Partition Tolerance—network failures will happen. So the real choice is between CP (consistent but may be unavailable during partitions) and AP (available but may return stale data during partitions).

CP vs AP Systems

CAP in Practice

Most systems aren't purely CP or AP—they make different trade-offs for different operations:

• Read your writes — after writing, you see your own write (even if others don't yet)
• Monotonic reads — you never see older data after seeing newer data
• Eventual consistency — all replicas converge eventually, but may diverge temporarily

PACELC: Beyond CAP

The PACELC theorem extends CAP: even when there's no Partition, you still trade off between Latency and Consistency.

PAC: During Partition, choose Availability or Consistency ELC: Else (no partition), choose Latency or Consistency

This explains why even systems with no partitions might choose eventual consistency—synchronous replication adds latency.

How They Relate

These characteristics don't exist in isolation—they interact and sometimes conflict:

Prioritization by Domain

Different systems have different priorities:

Quick Reference

Availability Targets

Consumer app: 99.9% (3 nines, 8.76 hours/year downtime)
Business critical: 99.99% (4 nines, 52.6 minutes/year)
Infrastructure: 99.999% (5 nines, 5.26 minutes/year)

Reliability Metrics

MTBF = Total operating time / Number of failures
MTTR = Total downtime / Number of failures
Goal: High MTBF, low MTTR

Scaling Decision

Quick fix or low traffic? → Scale up
Long-term growth? → Scale out
Stateless services? → Easy to scale out
Stateful (databases)? → Consider sharding

CAP Decision

Strong consistency required? → CP (PostgreSQL, etcd)
Availability over consistency? → AP (Cassandra, DynamoDB)
During normal operation? → You can often have both

What Interviewers Look For

When discussing non-functional requirements, interviewers want to see:

1. Trade-off awareness — you understand that improving one characteristic often costs another
2. Quantitative thinking — you can discuss availability in nines, calculate MTBF/MTTR
3. Prioritization — you choose the right trade-offs for the specific problem domain
4. Practical knowledge — you know which real systems make which trade-offs
5. Proactive thinking — you address failure modes before being asked

Don't just list characteristics—explain how they apply to your specific design and justify your trade-offs based on the problem requirements.