एका API ची p99 latency 3s आहे — तुम्ही ती कशी debug आणि optimize कराल?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: सर्वात हळू 1% requests ना 3s लागतात. पहिली चाल म्हणजे **measure करून breakdown करणे, अंदाज लावणे नाही**. p50 vs p99 ची तुलना करा — जर p50 fast असेल पण p99 3s असेल, तर path एकसमान हळू नाही; काहीतरी फक्त *load खाली किंवा edge cases मध्ये* चावते (pool saturation, GC pauses, N+1, cold cache, un-timed external call).

**Mental model:** p99 म्हणजे *सर्वात लांब checkout line*, average wait नाही — average वेगवान केल्याने मागे अडकलेल्या customer साठी काहीच होत नाही.

## The process (कुठून कुठे)
1. **Measure & break down** — RED metrics (Rate, Errors, Duration) + distributed tracing; p50/p95/p99 वाचा. त्यांच्यातील *gap* गोष्ट सांगतो.
2. **Localize the stage** — हळू requests कुठे वेळ घालवतात हे पाहण्यासाठी प्रत्येक step instrument करा; अंदाजावर optimize करू नका.

```js
// Time each stage to see where p99 piles up (don't guess)
async function handler(req, res) {
  const t0 = process.hrtime.bigint();
  const mark = (label) =>
    req.log.info({ label, ms: Number(process.hrtime.bigint() - t0) / 1e6 });
  const user = await db.user.find(req.id);   mark('db.user');
  const courses = await loadCourses(user);   mark('loadCourses'); // suspect
  res.json(courses);                         mark('total');
}
```

3. **Identify the tail suspect** — सहसा *waiting*, computing नाही: connection-pool exhaustion, N+1 queries, un-timed external calls, GC pauses, missing index, cold cache.

```js
// BEFORE: N+1 — N sequential round-trips, p99 blows up as N grows
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// AFTER: collapse to 1 query -> the tail drops (no more N sequential trips)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // one IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

इथे p50 (लहान N) ठीक दिसते, पण load खाली N वाढते आणि pool saturate होतो, त्यामुळे **p99 detonates**. External calls साठी नेहमी **timeout + circuit breaker** ठेवा जेणेकरून एक हळू dependency संपूर्ण endpoint च्या p99 ला ओढू शकत नाही.

4. **एक गोष्ट fix करा → p99 पुन्हा measure करा → पुन्हा करा.** एका वेळी एकच variable, नाहीतर काय मदत झाली हे कळणार नाही.
5. **Lock it in** — एक **SLO** सेट करा (उदा. p99 < 300ms) + alert जेणेकरून ते regress होणार नाही.

## Interview lens
Interviewer एक *methodical* process तपासत असतो, नशिबाचा अंदाज नाही: तुम्ही **tail ला mean पासून** वेगळे करता का, change करण्याआधी measure करता का, आणि CPU आधी **queues/locks (waiting)** पाहता का. कमकुवत उत्तर: "caching add करा / servers scale up करा." भक्कम उत्तर: measure → tracing ने localize → विशिष्ट tail cause fix → numbers ने verify.

## Principle
**Tail (p99) optimize करा, average नाही.** बहुतांश "3s p99" *waiting* (pool/queue/lock) मुळे येते, *computing* मुळे नाही — म्हणून CPU आधी queues पाहा.

The process (कुठून कुठे)

Interview lens

Principle

संबंधित प्रश्न