Before exploring the trade-offs, each vertex needs a precise definition. Vague understanding leads to vague decisions.
1. Velocity (Speed)
Velocity is the rate at which your team delivers value to users. Not the rate at which you write code — the rate at which working changes reach production. A team that merges 50 pull requests a week but deploys once a month has low velocity.
Velocity is measured by concrete metrics from the DORA (DevOps Research and Assessment) framework, a research program that identified the practices and metrics that distinguish high-performing software delivery organizations:
- Deployment Frequency: How often do you push to production? (Multiple times per day = elite; once per month = low.)
- Lead Time for Changes: How long from code commit to running in production? (Under one hour = elite; over six months = low.)
- Change Failure Rate: What percentage of deployments cause a production incident? (Under 5% = elite; over 30% = low.)
- Mean Time to Restore (MTTR): How quickly can you recover when a deployment causes a failure? (Under one hour = elite; over one week = low.)
High velocity looks like: a developer merges a PR at 10:00 AM, automated tests run, and the change is live by 10:15 AM. Low velocity looks like: a change request submitted in January ships in Q3 after three approval committees and a manual regression test cycle.
2. Reliability (Quality)
Reliability is the degree to which your system does what users expect, when they expect it. It encompasses multiple dimensions:
- Availability: Is the service up? Measured as a percentage of uptime. "Five nines" (99.999%) means roughly 5 minutes of downtime per year. "Three nines" (99.9%) allows about 8.7 hours of downtime per year. "Two nines" (99%) allows 87.6 hours — over three and a half days.
- Latency: Is the service fast? A page that loads in 200ms feels instant; one that takes 8 seconds feels broken, even if it technically "works."
- Correctness: Does the service produce the right results? A checkout system that charges the wrong amount is unreliable even if it's "up."
- Durability: Is data safe? Losing a customer's order history is a reliability failure even if the service never went down.
In SRE (Site Reliability Engineering) practice, reliability is formalized through three related concepts:
- SLI (Service Level Indicator): The raw metric you measure. Example: "the percentage of HTTP requests that return a 2xx status code within 500ms."
- SLO (Service Level Objective): The target you set for that metric. Example: "99.9% of requests must succeed within 500ms, measured over a rolling 30-day window."
- SLA (Service Level Agreement): The contractual promise you make to customers, usually with financial penalties (credits, refunds) if you breach it. SLAs are typically set below your SLO to give yourself a buffer.
3. Cost (Efficiency)
Cost is the total financial investment required to build and operate the system. It's broader than most people think:
- Infrastructure costs: Cloud compute, storage, networking, databases — your AWS/Azure/GCP bill.
- People costs: Salaries, benefits, and the opportunity cost of engineers working on one thing instead of another. This is almost always the largest cost in a software organization.
- Tooling costs: Licenses for CI/CD platforms, monitoring tools, security scanners, incident management systems.
- Operational costs: On-call burden, incident response time, manual toil that could be automated.
- Hidden costs: Technical debt that slows future development, knowledge silos that create bus-factor risk (where one person leaving breaks the team's ability to operate a system).
A common mistake is to equate "cost" with "cloud bill." In most organizations, engineer time is 5–10x more expensive than infrastructure. A $500/month server that saves an engineer 10 hours of manual work per month is almost always a good trade. The math: 10 hours × $150/hour fully-loaded engineer cost = $1,500 in saved labor for $500 in infrastructure. That's a 3x return.
Key Point: When evaluating cost, always include opportunity cost — what your engineers could be building instead. A team spending 40% of its time on manual deployments isn't just paying for that toil; they're paying for the features they didn't ship and the customers they didn't retain.