Service Component Classification
An easy SQL interview practice problem on DataDriven. Write the query and run it against a real database, with instant feedback.
- Domain
- SQL
- Difficulty
- easy
- Seniority
- L3
- Asked in
- ESPN
Problem
Every row of svc_health is one health check, so each service name repeats across many checks. List every service once with its classification: 'Multi-Component' when the name contains a hyphen, 'Single-Component' when it is a single bare word.
Classified by naming pattern.
Tables
svc_health
Columns: check_id INTEGER, svc_name TEXT, status TEXT, latency REAL, uptime REAL, checked TEXT, region TEXT
| check_id | svc_name | status | latency | uptime | checked | region |
|---|---|---|---|---|---|---|
| 137 | payment-api | degraded | 3.6 | 97.03 | 2026-02-02 01:05:00 | us-west-2 |
| 174 | user-svc | unhealthy | 6.7 | 94.06 | 2026-03-03 02:10:00 | eu-west-1 |
| 211 | search-api | timeout | 9.8 | 91.09 | 2026-04-04 03:15:00 | ap-south-1 |
| 248 | gateway | Healthy | 12.9 | 98.12 | 2026-05-05 04:20:00 | eu-central-1 |
| 285 | notif-svc | DEGRADED | 16 | 95.15 | 2026-06-06 05:25:00 | us-east-1 |
| 322 | ml-serving | healthy | 19.1 | 92.18 | 2026-07-07 06:30:00 | us-west-2 |
| 359 | cache-svc | degraded | NULL | 99.21 | 2026-08-08 07:35:00 | eu-west-1 |
| 396 | queue-worker | unhealthy | 25.3 | 96.24 | 2026-09-09 08:40:00 | ap-south-1 |
| 433 | cron-svc | timeout | 28.4 | 93.27 | 2026-01-10 09:45:00 | eu-central-1 |
| 470 | auth-svc | Healthy | 31.5 | 90.3 | 2026-02-11 10:50:00 | us-east-1 |
Expected output
| svc_name | svc_class |
|---|---|
| payment-api | Multi-Component |
| user-svc | Multi-Component |
| search-api | Multi-Component |
| gateway | Single-Component |
| notif-svc | Multi-Component |
Worked solution and explanation
This is a grain problem dressed up as string classification. The label is the easy half: anyone writes CASE WHEN svc_name LIKE '%-%'. What separates candidates is noticing that svc_health is a log of checks, not a catalog: 200 rows, 15 services. Project the label without collapsing it and you hand back 200 rows, with payment-api listed 18 times.
Read the grain first
Step 1: Name what one row of svc_health is
One row is one health check, keyed by check_id. The service name rides along on every check, so the ten original services repeat 18 times each and the five newer ones 4 times. The ask is one row per service, a coarser grain than the table, and that gap is the whole problem.
Step 2: Label the name with a two-sided LIKE
LIKE '%-%' means a hyphen anywhere, because the wildcards on both sides absorb whatever surrounds it. Fourteen names match. gateway is the one bare word, and it is why the ELSE branch exists at all.
Step 3: Collapse to one row per service with DISTINCT
svc_class is computed from svc_name alone, so every check for a given service produces the identical pair. DISTINCT over the pair yields exactly one row per name. No service can surface with two labels, so no tie rule or pick-one logic is needed.
SELECT DISTINCT
svc_name,
CASE
WHEN svc_name LIKE '%-%' THEN 'Multi-Component'
ELSE 'Single-Component'
END AS svc_class
FROM svc_health- Label projected off the log
- Without
DISTINCTyou get 200 rows, one percheck_id. Every label is right and the result is still wrong, because a catalog that listsauth-svc18 times is not a catalog. - Label collapsed to the service
- With
DISTINCTover (svc_name,svc_class) you get 15 rows, one per service, withgatewaythe lone 'Single-Component'.
SELECT
svc_name,
CASE
WHEN svc_name LIKE '%-%' THEN 'Multi-Component'
ELSE 'Single-Component'
END AS svc_class
FROM svc_healthCorrect labels at the wrong grain: one row per health check.
Common follow-up questions
- What changes if the log stores the same service as 'Payment-API' and ' payment-api'? (Tests whether you normalize `svc_name` with `TRIM` and `LOWER` before collapsing, so one service is not split into several.)
- Split the classification three ways: a bare word, two parts, and three or more parts like `edge-auth-svc`. (Tests `CASE` branch ordering with `LIKE '%-%-%'` placed before `LIKE '%-%'`.)
- How would you build this catalog without scanning all 365 partitions of `svc_health` every time? (Probes incremental maintenance: merging only names from new partitions into a services dimension.)