Six qualities that define every system
Latency, availability, consistency, durability, scalability, and throughput are not isolated vocabulary. They are the constraints you measure, trade, and defend in every system design.
Start with the right question
A fast system is not necessarily available. An available system is not necessarily consistent. Translate vague requirements into a number and a measurement window.
Latency
How long does one request take?
Availability
Can users reach the system?
Consistency
Do readers see the right data?
Durability
Will accepted data survive?
Scalability
Can capacity grow with demand?
Throughput
How much work finishes per second?
Latency
Latency is the elapsed time for one operation. Measure it from the user’s boundary—not only inside your service—and use percentiles to expose slow requests.
The database is the largest slice, so optimizing DNS would barely move the total.
Availability
Availability is the proportion of valid requests the system can serve successfully during a stated period. It includes planned and unplanned failure unless your contract says otherwise.
Two independent services with 99.9% availability called in sequence yield approximately 99.9% × 99.9% = 99.8%. Dependencies multiply risk. Redundancy, health checks, failover, timeouts, circuit breakers, and graceful degradation protect the request path.
Consistency
Consistency defines what a read may observe after writes occur. The right model is a product decision: bank balances and social-like counters have different correctness needs.
Eventual consistency accepts a short stale-read window. Strong consistency delays or rejects the read until the latest write is visible.
Strong
A completed write is immediately visible to subsequent reads. Useful for inventory reservations and balances.
Eventual
Replicas converge if writes stop. Useful for feeds, analytics, view counts, and caches.
Session guarantees
A user sees their own writes while other users may briefly see older data. Often the practical middle ground.
Durability
Durability is the probability that acknowledged data remains recoverable. Replication handles hardware loss; backups and recovery procedures handle corruption, deletion, and wider disasters.
Client sends order
Request exists only in transit
Write-ahead log
Append reaches durable storage
Database commit
Transaction becomes visible
Replicated copy
Survives a machine or zone failure
Backup + restore test
Survives corruption or deletion
RPO
How much data can we lose?
Example: at most 5 minutes
RTO
How long can recovery take?
Example: restore within 30 minutes
Retention
How far back can we recover?
Example: 35 daily backups
Scalability
Scalability is the system’s ability to handle more load by adding resources while keeping service targets and cost within acceptable bounds.
Scale up
vertical32 GB RAM
256 GB RAM
Simple, but hardware has a ceiling and one machine remains a failure domain.
Scale out
horizontalMore capacity and resilience, but coordination, partitioning, and consistency become harder.
If doubling servers raises throughput from 10,000 to only 13,000 requests/s, efficiency is 30%, not 100%. A shared database, lock, network link, or coordination step is probably limiting growth. Partition data and work only after identifying that bottleneck.
Throughput
Throughput is completed work per unit time: requests per second, transactions per second, events per second, or bytes per second. Count completed work, not merely accepted work.
requests/s
API
8k req/s
Workers
5k jobs/s
Database
2k writes/s
At 5,000 requests/s and 200 ms average latency, about 1,000 requests are concurrently in flight. Reducing latency can therefore increase throughput by releasing connections, threads, memory, and queue slots sooner.
Trade-offs, not trophies
No architecture maximizes all six qualities at once. Strong design explains which quality matters most, where the boundary sits, and how the decision is measured.
| Decision | Usually improves | Usually costs |
|---|---|---|
| Add a cache | Latency ↓ Throughput ↑ | Consistency becomes harder |
| Synchronous replication | Durability ↑ Consistency ↑ | Write latency ↑ Availability may ↓ |
| Async queue | Peak throughput ↑ Availability ↑ | Freshness ↓ Operational complexity ↑ |
| More replicas | Read throughput ↑ Availability ↑ | Cost ↑ Replica lag appears |
| Batch writes | Throughput ↑ | Per-item latency ↑ |
Payments
Prefer correctness and durability. Accept somewhat higher write latency. Use idempotency, a durable ledger, synchronous commit, and reconciliation.
Social feed
Prefer availability and read throughput. Accept brief staleness. Use caches, asynchronous fan-out, replicas, and graceful degradation.
An interview-ready answer
Use this sequence whenever an interviewer asks about a non-functional requirement.
- 01Name the quality precisely.
- 02Attach a target and measurement window.
- 03Estimate the expected and peak load.
- 04Choose mechanisms that protect the target.
- 05State the quality you traded away.
- 06Describe how you monitor and recover.
A concise example
“For checkout, I’ll target 99.99% availability and p99 latency below 500 ms. Payment writes require strong consistency and synchronous multi-zone durability. I’ll preserve availability for non-critical recommendations through timeouts and graceful degradation. The trade-off is higher payment latency and infrastructure cost, monitored through success rate, p99 latency, replication lag, and reconciliation errors.”
Continue learning
Explore every Fundamentals lesson