Breaking your REST APIs to make them stronger!!
summary
Claims that deliberate destructive tests reveal hard-to-find failures and reduce huge late fixes: uses k6 open source + k6 cloud to run load, stress and open-model RPS tests, hits 11,300 RPS in examples and notes theoretical ~400k; uses Azure App Service and Application Insights to observe failures. Shows a sneaky memory leak (static list that adds ~15MB per call), a CPU-bound PI calculation with P95 targets ~10–90ms but spikes to seconds, and fixes via HTTPClientFactory and Polly and architectural patterns.
AI-written summary · about
chapters (8)
- 0:00Introduction and speaker intro
- 2:09Why breaking APIs matters
- 10:16Concepts behind API stress testing
- 17:59Case study: Memory cobbler
- 29:24Case study: Evil APIs
- 38:25Case study: Hidden spikes
- 50:25Key learnings and recommendations
- 52:12Q&A and closing
related talks
34mPerformance testing: from zero to hero with k6 & Azure
14mBreaking the build with K6 load tests
15mAre Your APIs Performing Enough? Not Sure, Let’s Test It Then
41mResillient Microservices without the Chaos
21mCrunching Millions of Requests for Breakfast: A Tale of Performance Testing Prowess
38mPerformance Testing sucks! How to get started testing RESTful APIs and GraphQL
43mPeter Paul Bakker: The Power of Automated Resilience Tests
01h 10mPerformance Testing Crash Course