System designMedium~16 minCore Designs / 23 of 30

Interview question

Design a backend feature where users save search filters and receive alerts when new matching items appear.

Design saved searches and alerts

Designs saved filters, scheduled matching, alert delivery, and freshness trade-offs for search-driven product workflows.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would store the saved search as validated filter criteria owned by a user, not as arbitrary query text. A scheduled worker would evaluate active saved searches against new or changed items, create alert records, and send notifications through the normal notification system. The API would let users create, pause, edit, delete, and view recent matches.

Full answer below

Practice focus

Search filter persistence, query validation, scheduled evaluation, alert deduplication, notification delivery, and freshness.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Saved alerts connect search, background jobs, and notifications. The interview value is in defining what gets saved, how often it runs, and how duplicate alerts are avoided.
I would store the saved search as validated filter criteria owned by a user, not as arbitrary query text. A scheduled worker would evaluate active saved searches against new or changed items, create alert records, and send notifications through the normal notification system. The API would let users create, pause, edit, delete, and view recent matches.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid scanning every saved search against the entire dataset every minute. The design can use item change events, last-checked cursors, indexed timestamps, or batching by common filters. Alert records need deduplication so the same item is not sent repeatedly for the same saved search. Search filters need versioning or migration behavior when the product changes available fields.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would define freshness expectations and capacity limits. Some products can run alerts every few minutes; others need daily digests. I would add quotas per user, validation for expensive filters, backoff when search infrastructure is unhealthy, and telemetry for evaluation lag, matches found, duplicate suppression, and notification failures. Privacy matters too: alerts must only include items the user is allowed to see at send time.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Saving raw search query strings without validation.
Re-alerting the same item every time the job runs.
Ignoring authorization when sending alert content.
Running unbounded full scans for every saved search.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain freshness versus cost.
No deduplication model for alerts.
No migration path when filter fields change.
Treats alert delivery as separate from user preferences.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you avoid duplicate alerts?
How fresh do alerts need to be?
What happens if a saved filter becomes invalid?

Continue the section

Next in Core Designs: Notification Preferences

Step 24 of 30

Design notification preferences and digests

Opening drill

System designMedium~16 minCore Designs / 23 of 30

Interview question

Design a backend feature where users save search filters and receive alerts when new matching items appear.

Design saved searches and alerts

Designs saved filters, scheduled matching, alert delivery, and freshness trade-offs for search-driven product workflows.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Search filter persistence, query validation, scheduled evaluation, alert deduplication, notification delivery, and freshness.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Saved alerts connect search, background jobs, and notifications. The interview value is in defining what gets saved, how often it runs, and how duplicate alerts are avoided.
I would store the saved search as validated filter criteria owned by a user, not as arbitrary query text. A scheduled worker would evaluate active saved searches against new or changed items, create alert records, and send notifications through the normal notification system. The API would let users create, pause, edit, delete, and view recent matches.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would avoid scanning every saved search against the entire dataset every minute. The design can use item change events, last-checked cursors, indexed timestamps, or batching by common filters. Alert records need deduplication so the same item is not sent repeatedly for the same saved search. Search filters need versioning or migration behavior when the product changes available fields.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would define freshness expectations and capacity limits. Some products can run alerts every few minutes; others need daily digests. I would add quotas per user, validation for expensive filters, backoff when search infrastructure is unhealthy, and telemetry for evaluation lag, matches found, duplicate suppression, and notification failures. Privacy matters too: alerts must only include items the user is allowed to see at send time.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Saving raw search query strings without validation.
Re-alerting the same item every time the job runs.
Ignoring authorization when sending alert content.
Running unbounded full scans for every saved search.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain freshness versus cost.
No deduplication model for alerts.
No migration path when filter fields change.
Treats alert delivery as separate from user preferences.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you avoid duplicate alerts?
How fresh do alerts need to be?
What happens if a saved filter becomes invalid?

Continue the section

Next in Core Designs: Notification Preferences

Step 24 of 30

Design notification preferences and digests

Design a backend feature where users save search filters and receive alerts when new matching items appear.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Design a backend feature where users save search filters and receive alerts when new matching items appear.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section