# Monthly Active Users per Endpoint

> One endpoint, many users. Which ones showed up?

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

Domain: SQL · Difficulty: easy · Seniority: L3

## Problem

The API product team needs to size per-endpoint user reach during June 2025 to inform deprecation decisions. For each endpoint, how many unique users called it that month?

## Worked solution and explanation

### Why this problem exists in real interviews

The api_calls table contains endpoint and method values that must be processed with grouping and date extraction. This appears as a fundamentals check to probe whether you reason about the correct aggregation grain before writing any window or GROUP BY clause.

---

### Break down the requirements

#### Step 1: Filter to the target rows

Apply the date filter using `STRFTIME` to extract and compare the relevant time component. This restricts rows before aggregation.

#### Step 2: Aggregate with COUNT DISTINCT

Group by the output grain and apply `COUNT DISTINCT()` to compute the metric. The `GROUP BY` must match exactly what the output needs: one row per group key.

#### Step 3: Order the final output

Apply `ORDER BY` as specified to produce the expected row sequence. When tied values exist, add a secondary sort column for determinism.

---

### The solution

**Date-filtered COUNT DISTINCT per group**

```sql
SELECT endpoint, COUNT(DISTINCT user_id) AS unique_users
FROM api_calls
WHERE STRFTIME('%Y-%m', call_time) = '2025-06'
GROUP BY endpoint
ORDER BY unique_users DESC
```

> **Cost Analysis**
>
> The query scans 200M rows from `api_calls`.

> **Interviewers Watch For**
>
> Explaining why `ROW_NUMBER` is preferred over `DISTINCT` for deduplication shows you understand the difference between collapsing and selecting.

> **Common Pitfall**
>
> Comparing dates stored as TEXT without casting can produce lexicographic instead of chronological ordering. Always confirm the column type.

---

## Common follow-up questions

- What happens to your result if api_calls.err_msg contains NULLs for some rows? _(Tests whether the candidate accounts for NULL behavior in aggregates and comparisons on err_msg.)_
- How would you verify that your aggregation on api_calls.call_id is not double-counting due to duplicate rows? _(Tests data quality awareness and deduplication strategies.)_
- With millions of distinct values in api_calls.call_id, what index strategy would you use to keep this query performant? _(Tests indexing knowledge specific to high-cardinality columns like call_id.)_

## Related

- [All practice problems](https://datadriven.io/problems)
- [Mock interview mode](https://datadriven.io/interview/monthly_active_users_per_endpoint)
- [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.