Madhav University Students: Caching and Performance Basics for a Backend Internship Demo

To show caching or indexing works in a backend internship demo, measure the same endpoint under the same conditions before and after one change, and report percentile latencies rather than a single average. This worksheet gives you a 14-day plan, a measurement protocol and a results table you can paste into your report.

Why a measured before-and-after beats a claim of “it’s faster now”

Reviewers of a short internship project see many demos that say “I added Redis and it became fast.” That sentence proves nothing. A measured experiment proves three things: you can define a baseline, you can change one variable, and you can report honestly what happened, including when the gain is small.

The experiment below is deliberately small. One endpoint, one change, one results table. A tight experiment you can explain line by line is worth more than a sprawling project you cannot defend.

The experiment worksheet: fields to fill in before you write any code

Copy this list into your notes and complete it first. Each blank forces a decision that otherwise surfaces as confusion on day 10.

1. Endpoint under test: method and path, for example GET /products/{id} or GET /reports/top-sellers.
2. Hypothesis: one sentence, such as “Adding an index on orders.customer_id will cut p95 latency of the order-history endpoint by at least half.”
3. Change being tested: exactly one of: an in-process cache, an external cache such as Redis, an HTTP cache header, or a database index. Not two at once.
4. Dataset size: number of rows in each relevant table. An index on 50 rows shows nothing; seed thousands or hundreds of thousands.
5. Machine and environment: OS, CPU and RAM, Python version, framework and version, database and version, whether the client and server share a machine.
6. Load pattern: number of requests, concurrency level, warm-up requests discarded, and whether requests use the same key or varied keys.
7. Metrics: median (p50), p95, maximum, requests per second, error count.
8. Success criterion: the number that would make you call the change worthwhile, set before measuring.
9. Correctness check: how you will confirm the response is identical (or acceptably fresh) after the change.

Choosing between a cache and an index for your demo

The two techniques fix different problems. Choosing the wrong one produces a flat result and a confusing report.

Designing a fair measurement: the rules that keep your numbers honest

• Change one thing. If you add an index and a cache together, you cannot say which helped.
• Discard warm-up. The first requests include imports, connection setup and cold database pages. Run 20 to 50 requests and ignore them.
• Repeat the run. Do at least three runs per condition and report the spread, not only the best.
• Keep the data identical. Seed with a fixed random seed so before and after use the same rows.
• Close noisy programs. Browsers and video calls distort laptop timings.
• Separate cold cache from warm cache. Report both: the first request after a flush and the steady state.
• Record the query plan. For an index test, save the output of EXPLAIN (or EXPLAIN ANALYZE in PostgreSQL) before and after.

A minimal timing harness in Python

The snippet below is illustrative: it shows the shape of a harness and has not been executed here. Adapt the URL, request count and parsing to your own project, and test it on your machine.

import time
import statistics
import requests

URL = "http://127.0.0.1:8000/products/42"
WARMUP = 30
N = 300

for _ in range(WARMUP):
    requests.get(URL)

times = []
errors = 0
for _ in range(N):
    start = time.perf_counter()
    r = requests.get(URL)
    elapsed_ms = (time.perf_counter() - start) * 1000
    if r.status_code != 200:
        errors += 1
    times.append(elapsed_ms)

times.sort()
p50 = statistics.median(times)
p95 = times[int(0.95 * len(times)) - 1]
print(f"p50={p50:.1f} ms  p95={p95:.1f} ms  max={times[-1]:.1f} ms  errors={errors}")

This sends requests one after another, so it measures latency but not behaviour under concurrency. If you want concurrent load, a dedicated tool such as Locust, wrk or ApacheBench can be added, but only if you can explain what its output means. Always save the raw numbers to a file so the report can be rebuilt.

Illustrative walk-through: indexing an order-history endpoint

The figures below are invented to show how to reason; they are not real measurements. Suppose you build GET /customers/{id}/orders on a table with 500,000 seeded orders and no index on customer_id.

1. Baseline: three runs of 300 requests give p50 around 180 ms and p95 around 240 ms. EXPLAIN shows a sequential scan.
2. Change: create an index on orders(customer_id), then run the database’s statistics update so the planner knows about it.
3. After: three more runs give p50 around 6 ms and p95 around 11 ms. EXPLAIN now shows an index scan.
4. Correctness: compare response bodies for 20 customer IDs before and after; they match.
5. Side effect: time 10,000 inserts before and after. A small slowdown in write time goes in the report as a trade-off.

Reading it: the drop is large because the table is large and the filter is selective. With 200 rows the same index would show almost no difference, and saying so is a legitimate finding.

Cache-specific checks: hit rate, expiry and stale data

If your change is a cache, measure more than speed.

• Hit rate: hits divided by total lookups. Log both counters.
• Expiry (TTL): state the value and justify it. A 60-second TTL means data can be up to a minute old.
• Invalidation: describe what happens when the underlying row is updated. Either delete the key on write, or accept staleness up to the TTL and say so.
• Cold versus warm: the first request after a flush is no faster than before; only repeated keys benefit.
• Memory: note the cache size limit and what happens when it fills.
• Failure mode: if the cache is unreachable, does the endpoint fall back to the database or return an error? Test it once and record the result.

Results table format for your final internship report

Use one table per experiment. Fill every cell; write “not measured” rather than leaving blanks.

Below the table, add a short block with these headings: environment, dataset size, load pattern, query plan before and after, correctness check, and a two-sentence conclusion that states whether your success criterion was met.

A 14-day plan for the caching experiment

A two-week internship leaves little room for drift. This schedule fits the experiment around a small API. The free two-week online internship from CareerSwami uses the same 14-day length, so you can follow this plan alongside whichever track you choose.

Madhav University students: what is known and what to verify before you plan

Madhav University’s About page says it was established under Act No. 7 of 2014, is recognised by the UGC and holds a NAAC “A” grade. It describes Certificate, Diploma, UG, PG and Doctoral programmes across faculties including Engineering & Technology and Commerce & Management. Teaching is described as run by the university’s own faculties, so questions about internship rules most likely go to the university itself rather than a separate affiliating body.

The Training & Placement Cell page (2026) names Dr. Jigar Y. Soni as Joint Director and lists activities such as pre-placement training, mock interviews and career counselling. It also says the cell helps students find summer and winter industrial internships with live projects. That is a description of a service, not a regulation on duration, credits or evaluation. The page also carries self-reported figures such as “100% Placement Support”; treat those as marketing language and ask for data if it matters to you.

What this means for your demo: a measured caching or indexing experiment is a project you can show a T&P officer, a faculty mentor or an interviewer regardless of the rules. But no official internship or project-work regulation has been verified here, so do not assume that an online internship, or this worksheet, counts for credit or satisfies a departmental requirement. Semester break timing is also unverified; the university home page links to the Academic Calendar and Examination pages, which are the place to check dates.

Verification steps:

1. Open the Academic Calendar from the university home page and note the semester break dates before you commit to a 14-day window.
2. Email or visit the T&P Cell and ask in writing: “Is a self-arranged online internship recognised, and what documents do you need?”
3. Ask your department coordinator whether any internship or project-work rule applies to your programme and scheme year, and request the document.
4. If you want credit, ask what evidence is required: an offer letter, completion certificate, report format or faculty sign-off.
5. Ask whether your faculty prefers a particular report template, and adapt the results table above to fit it.
6. Keep the reply emails; they are your record if requirements are questioned later.

Report-writing mistakes that weaken a performance experiment

• Reporting only the average. A few slow requests hide inside a mean. Show p50 and p95.
• Testing against a tiny table. Small data makes every query fast and every index look pointless.
• Measuring over a noisy network. If the endpoint calls a remote database, say so, because network time dominates.
• Ignoring correctness. A fast wrong answer is a failure. Show the comparison.
• Hiding a null result. “The index was not used because the planner preferred a scan on this small table” is a valid, educational finding.
• Claiming more than you measured. Say “on my laptop, with 500,000 rows” rather than “the API is 30x faster.”

What to say when you demo it

Prepare a three-minute walk-through: the problem, the hypothesis, the one change, the table, and the trade-off. Interviewers tend to ask what happens when the cached data goes stale, why you chose that TTL, and what the query plan showed. If you have answers grounded in your own numbers, the demo stands on its own. The CareerSwami internship gives a free offer letter and a free completion certificate after successful completion, but the experiment itself is the evidence of what you can do.

Frequently Asked Questions

How many requests do I need for a reliable result?

A few hundred per run, repeated three times, is enough for a small demo. What matters more is that the conditions are identical across runs and that you discard warm-up requests.

Should I use Redis or a simple in-process dictionary?

For a first experiment, an in-process cache with a TTL is easier to reason about. Redis is worth using if you want to show a shared cache across multiple server processes; just record the network hop in your notes.

Why is my p95 worse after adding a cache?

Misses now pay for the lookup plus the original work, and a cold cache makes early requests slower. If your keys rarely repeat, the hit rate will be low and the cache adds overhead. Report the hit rate alongside latency.

Can an index make things slower?

Yes. Indexes slow inserts and updates and use storage. On very small tables the planner may ignore the index. Measure write time and check the query plan to see what actually happened.

Do I need a chart in the report?

No, but a simple bar chart comparing p50 and p95 before and after helps a reader see the result quickly. The table with raw numbers matters more.

Will this experiment count for credit at Madhav University?

That is not verified. No official internship or project-work regulation was confirmed, so ask your department and the T&P Cell in writing what is recognised and what documents they require.

Which framework should I use for the demo API?

Use whichever you can explain: Flask, FastAPI or Django are all fine. The experiment depends on the endpoint, data size and measurement discipline, not the framework.

What if my result shows no improvement?

Report it with the evidence: the query plan, hit rate and data size. Explaining why a change did not help shows more understanding than a forced success.

Related Python & Backend Engineering guides

• Sharnbasva University Students: Learning Backend Python on a Phone and Shared Laptop
• Atlas SkillTech University Students: Presenting Your Backend Internship Project in a Five-Minute Demo
• Chhatrapati Shahu Ji Maharaj University Students: Data Validation in Python APIs With Pydantic Exercises
• All Python & Backend Engineering internship guides