Low-Latency Read API Case Study

Problem

Performance advice is usually passed on as a checklist. Students repeat it without knowing which items matter for their workload, how much each one helps, or what it costs in complexity. A measured case study answers those questions with numbers you produced yourself.

What you build

• A read-heavy API over a realistic dataset, for example a course catalogue or a product catalogue with a few million rows and related tables such as sections, reviews and prices.
• A baseline that is slow in common, realistic ways: a new database connection per request, no indexes beyond primary keys, N+1 queries, offset pagination, large uncompressed JSON responses and no HTTP caching headers.
• A series of steps, each a tagged commit, applied one at a time:
  1. connection pooling;
  2. indexes chosen from EXPLAIN ANALYZE output;
  3. removing N+1 queries and switching to keyset pagination;
  4. an in-memory cache in Redis, cache-aside, with a stated invalidation rule;
  5. gzip or brotli compression and smaller response payloads;
  6. HTTP caching headers and a CDN in front of cacheable endpoints.
• A benchmark harness that runs the same k6 scenario against every step and stores the results.

Suggested architecture

• Node.js or Go for the API, PostgreSQL, Redis, Nginx as a reverse proxy, and a free CDN tier such as Cloudflare. Any backend language works; keep the same one across every step.
• Run the database and API on fixed, documented hardware. A small cloud VM is better than a laptop that is also running a browser.
• Use k6 with a constant arrival rate executor, so a slow server cannot quietly reduce the load it is tested with.
• Measure from at least two places: a machine in the same region, and a distant client (for example Lahore against a European region), because the CDN step only shows up for distant users.

Milestones by month

1. Month 1: dataset generator, baseline API, benchmark harness, first baseline numbers.
2. Month 2: steps 1 to 3, each measured and written up.
3. Month 3: steps 4 to 6, including cache invalidation tests and CDN measurements from two locations.
4. Month 4: combined results, an ablation that removes each step from the final version to see what it contributes, report and demo.

How it will be assessed

• A results table and charts: p50, p95, p99, throughput and error rate for every step, with the hardware and load described.
• Reproducibility: an examiner can check out any step's tag and rerun the benchmark with one command.
• The quality of the explanations. "Latency fell by 60% because the query moved from a sequential scan to an index scan, shown in this plan" is the standard to aim for.
• Honest reporting of steps that made no difference or made things worse.

Pitfalls

• Changing two things in one step.
• Measuring with a cold cache in one run and a warm cache in the next without saying so.
• Reporting averages instead of percentiles.
• Benchmarking a dataset so small that it fits in memory, which makes indexes look useless.
• Caching data that must be fresh without a clear invalidation rule. Write down how stale each endpoint is allowed to be.