We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Devops Cicd
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
An API endpoint responded in 50ms during development. After 6 months of feature additions (more database joins, extra validation, logging middleware, analytics events, checks), the same endpoint took 800ms. Nobody noticed because the degradation was gradual: 50ms, then 60ms next week, then 80ms, then 150ms. No single change caused the slowdown. Dozens of small changes accumulated.
When customers started complaining about "the app feeling slow," the team had no baseline to compare against. They could not answer: "When did this endpoint get slow?" or "Which commit caused the 150ms to 300ms jump?" They spent two weeks profiling and bisecting commits to find the causes.
Performance testing establishes baselines and tracks them over time. Every build is measured. A 10% regression on any endpoint fails the build. Gradual degradation is caught at the PR level, not 6 months later when customers complain.
Performance testing measures four things. Each requires different tools and different thresholds.
| Dimension | What It Measures | Typical Tool | Example Budget |
|---|---|---|---|
| Time to respond (p50, p95, p99) | k6, Artillery, wrk | p99 < 500ms | |
| Requests handled per second | k6, wrk, vegeta | > 5,000 RPS | |
| Resource usage | CPU, memory, disk I/O, connections | , cAdvisor | < 70% CPU at peak |
| Scalability | How metrics change as load increases | Load test with ramp-up | Linear scaling to 10x |
Performance budgets turn these into enforced limits:
| Budget Type | Example | Where Enforced |
|---|---|---|
| API latency | p99 < 500ms for /api/checkout | k6 threshold in CI |
| Page load | LCP < 2.5s on mobile 3G | Lighthouse CI |
| JavaScript bundle | < 200KB compressed | Bundlewatch in CI |
| Container memory | < 512MB per pod | resource limits |
| Database queries | < 50ms for any single query | pg_stat_statements + alerting |
Google's web performance team published data showing that a 100ms increase in mobile page load time decreases conversion rate by 1.1%. Amazon found that every 100ms of added latency cost them 1% in revenue. These are not theoretical numbers. They are production measurements from A/B tests.