Go from “it feels slow” to a named cause and a measured before/after — in one sitting, not a week of guesswork.
An endpoint that used to answer in 80 ms now takes four seconds, the dashboard is red, and nobody on the team can say why. This course lives in that moment. You start by making “slow” measurable — time to first byte (TTFB), turnaround time, and the 99th-percentile latency (p99) that your unluckiest one percent of users actually feel — using curl timing flags, Server-Timing headers, and the browser waterfall. Then you eliminate layers in order: the network (DNS, handshakes, distance), the database (EXPLAIN plans, missing indexes, the N+1 pattern where an ORM quietly fires one query per row, connection pool sizing), your own process (blocking I/O, garbage-collection pauses, flame graphs), caching, third-party calls, and serverless cold starts. Later modules turn measurement into infrastructure: OpenTelemetry traces, RED-method dashboards, alerts tied to an error budget, and k6 load tests that find the point where throughput stops rising. You finish with a written playbook, a postmortem, and a runbook you can hand to whoever is on call next.
Built by Lakshya Kumar
Paste this into any AI chat. Fill in the bracketed parts with your context — you'll get back a straight answer on whether this belongs on your plate.
We grant free access case-by-case — students, career-switchers, builders on a tight budget. Sign in to send us a note.
Sign in to applyFinished the tasks? Take the prompt to your AI and get tested on it. We copy the prompt and open the app — just paste it in.
Distance, handshakes, and protocol choice can cost more than your handler ever will — measure that share, then cut it.
Read a query plan like a report card, catch the per-row query loop your ORM hides, and size pools before load finds the ceiling.
Blocked event loops, garbage-collection pauses, and starved thread pools stay invisible to metrics — profiling drags them out.
Work out the hit rate your target actually needs, survive the rush when a hot key drops, and invalidate without serving lies.
One slow vendor can hold every thread you own — timeout budgets, backoff, and circuit breakers keep their outage out of yours.
Find which init phase is costing you the extra second, then decide whether keeping functions warm is worth what it charges.
Traces, RED dashboards, and alerts tied to a burning error budget — so the next regression names itself before a user does.
Push the service until it buckles in a test you control, and learn exactly which resource gives out first and why.
A repeatable order of elimination plus the postmortem and runbook that stop the same regression from landing twice.
Complete all modules, then submit the required number of capstone projects. Each must earn a passing rating from an admin reviewer.
Pick any API (your own project, an open-source backend, or a public API). Run a full performance audit: baseline the p50/p95/p99 with your benchmark script, identify the single biggest bottleneck using the techniques from the course, fix it, and prove the improvement with a before/after benchmark. Deliver a written report that names every tool used, every suspect eliminated, and the measured result.
I'm considering a "Debugging Slow APIs" course. It starts with measurement vocabulary (TTFB, p99, SLOs), works through the network layer, database bottlenecks, server-side profiling, caching, external dependencies, serverless cold starts, observability, and load testing, and finishes with a systematic debugging playbook. Context about me: 1. My current role: [e.g. "backend dev", "full-stack engineer", "DevOps/SRE", "frontend dev who gets blamed for slow APIs"] 2. The slowest API problem I've personally dealt with: [e.g. "never debugged one", "a query that took 8s with no indexes", "a cold start on Lambda that ruined our checkout"] 3. What I'm hoping this changes: [e.g. "I can diagnose any slow API in under 30 minutes", "I stop guessing and start measuring", "I can write SLOs my team actually uses"] Answer these: - For my background, which module will give me the fastest ROI in the next month, and why? - Name one concrete thing I'll be able to do after this course that I can't do today. - Is there a faster path for someone who only cares about one layer (e.g. just DB, just network)? - What will I NOT learn here that I might expect? (e.g. "you will not learn how to provision infrastructure", "you will not learn Kubernetes")
Find an API endpoint with N+1 queries (yours or from a sample app). Implement at least three solutions (DataLoader, prefetch joins, query batching) and benchmark each. Produce a report showing latency reduction at P50/P95/P99 and the cost trade-offs of each approach.
Take an API with P99 latency more than 5x its P50. Identify the cause via profiling (GC pauses, lock contention, slow downstream, large response). Implement at least three optimizations, measure the result, and prove the new P99 is within 2x of P50.
Design and implement a 3-tier cache (in-process, Redis, CDN) for a high-traffic endpoint. Include cache invalidation strategy, stampede protection (singleflight), and a measurement showing cache hit rate, origin load reduction, and stale-while-revalidate behavior.
Build a rate limiter for an API: token-bucket per user + global, distributed via Redis with Lua script for atomicity. Include burst handling, fair-share across tiers, an admin-overridable allowlist, and a 10k-rps load test demonstrating correct throttling without false positives.
Free online. The network-layer module draws heavily from chapters 2, 4, and 9.