# Peak Concurrent Pods

> The most pods alive at once.

Canonical URL: <https://datadriven.io/problems/peak_concurrent_pods>

Domain: SQL · Difficulty: hard · Seniority: L4

## Problem

Each pod occupies a node from its start time to its stop time. What is the maximum number of pods running simultaneously across the entire dataset? Return a single count.

## Worked solution and explanation

### Why this problem exists in real interviews

Capacity planning teams ship this question to see if you recognize a concurrency problem when you see one. They want to hear you say 'maximum overlapping intervals' out loud before you touch the keyboard. If you reach for `GROUP BY hour` on `k8s_pods`, you've quietly redefined the metric to 'pods seen in a bucket' and the interviewer now doubts your instinct for grain.

---

### Break down the requirements

#### Step 1: Name the pattern aloud

This is interval overlap on `k8s_pods`. Each row has an implicit lifetime from start to stop. Peak concurrency means the time point covered by the most lifetimes. Say that to the interviewer before writing.

#### Step 2: Pick a sweep anchor

Every overlap maximum sits at some pod's start instant. So self-join `k8s_pods a` to `k8s_pods b` and, for each `a`, count how many `b` rows are alive at `a`'s start point.

#### Step 3: Express the overlap predicate

Two pods overlap when one starts before the other ends and vice versa. Use an inequality join on the lifetime columns plus `a.pod_id != b.pod_id` so a pod doesn't count itself.

#### Step 4: Collapse to a scalar

Group by `a.pod_id` to get a per-anchor overlap count, then wrap the subquery in `MAX(overlap_count)` so the final result is one number, not a table.

---

### The solution

**PEAK CONCURRENT PODS VIA SELF JOIN**

```sql
SELECT MAX(overlap_count) AS peak_concurrent_pods
FROM (
  SELECT a.pod_id,
         COUNT(*) AS overlap_count
  FROM k8s_pods a
  JOIN k8s_pods b
    ON a.pod_id != b.pod_id
  GROUP BY a.pod_id
) sub
```

> **Cost Analysis**
>
> Self-join on 3,000,000 `k8s_pods` rows is the cost driver. A naive cross product is 9e12 pairs. In production you'd add the time-range inequality and an index on the lifetime columns so the planner can do a range scan per outer row instead of a full hash join.

> **Interviewers Watch For**
>
> Ask: 'Do you want concurrency at any instant, or peak per minute bucket?' The first is sweep-line, the second is `GROUP BY date_trunc`. Confirming this before writing is the signal they're scoring. Also confirm whether a pod still in `status='Running'` counts as alive at now().

> **Common Pitfall**
>
> Writing `SELECT COUNT(DISTINCT pod_id) FROM k8s_pods GROUP BY hour_bucket ORDER BY 1 DESC LIMIT 1`. That counts pods that appeared during the hour, not pods alive at the same instant. A pod that ran for ten seconds and another that ran for fifty minutes both add one to the bucket.

---

### COMMON FOLLOW-UP QUESTIONS

## Common follow-up questions

- How would you find the exact timestamp when peak concurrency occurred, not just the count? _(Probes whether you can extend the sweep-line to return the anchor row alongside the max.)_
- Rewrite this using a UNION ALL of (+1 at start, -1 at stop) with a running sum. _(Tests the event-stream formulation of interval overlap, the version that scales past a few million rows.)_
- How does the answer change if pods can restart and you only have one row per pod? _(Forces a grain conversation: is `restarts` a count or a list, and do restarts produce gaps in the lifetime.)_
- What index would you add to make this query usable on 100M rows? _(Checks whether you reach for a composite index on the lifetime columns and understand range-scan vs hash-join tradeoffs.)_

## Related

- [All practice problems](https://datadriven.io/problems)
- [Mock interview mode](https://datadriven.io/interview/peak_concurrent_pods)
- [SQL Interview Questions](https://datadriven.io/sql-interview-questions)
- [Data Engineering Interview Prep Guide](https://datadriven.io/data-engineer-interview-prep)
- [Daily Challenge](https://datadriven.io/daily)

---

Source: DataDriven (https://datadriven.io). 100% free data engineering interview prep. Live code execution against Postgres 16, Python 3.11, and Spark sandboxes. No paywall, no premium tier, no signup gate.