Skip to main content

SECTION 0 — SEARCH IS UX + DATA + PERFORMANCE

Search systems fail when teams treat them as “just an endpoint.”

Senior fullstack means you design:

  • fast interactive UX

  • correct filtering semantics

  • indexing + freshness strategy

  • predictable latency

SECTION 1 — REQUIREMENTS

  • Keyword search with filters (status, tags, date range).

  • Sort by relevance, optionally by recency.

  • Highlight matches.

  • Support pagination.

Non-functional:

  • p95 response under a target (e.g., 250ms) for interactive UX.

  • stable semantics across web/mobile.

SECTION 2 — DATA + INDEX MODEL

Options:

  • SQL LIKE / full-text (simple, limited)

  • dedicated search engine (Elasticsearch/OpenSearch/Meilisearch)

Senior default at scale:

  • dedicated index for relevance + filtering.

  • DB remains source of truth.

Index pipeline:

  • write to DB

  • emit event

  • async index update

Define freshness:

  • “search may lag by up to X seconds.”

SECTION 3 — API CONTRACT (SEARCH REQUEST IS A SPEC)

  • GET /search?q=...&filters=...&sort=relevance&cursor=...

Response:

  • results: SearchResult[]

  • nextCursor

  • tookMs (from search engine)

  • generatedAt

Filter semantics rules:

  • explicit AND/OR rules

  • stable naming for filter keys

  • validate unknown filters

SECTION 4 — UI LATENCY BUDGETING

Interactive search targets:

  • keypress → results update within ~150–300ms perceived

Techniques:

  • debounce input (e.g., 150–250ms)

  • cancel in-flight requests

  • keep previous results while loading

  • show “refining…” state

Senior rule:

Don’t make the user pay for your backend variability.

SECTION 5 — PAGINATION + CONSISTENCY

Use cursor-based pagination.

Cursor can include:

  • last relevance score

  • tie-breaker ID

  • query+filter hash

If index is eventually consistent, communicate:

  • “results updated” banner

  • manual refresh

SECTION 6 — FAILURE MODES

  • index lag → missing newly created items

  • stale results → user confusion

  • partial outage of search engine → fallback to DB basic search

  • relevance regressions → add eval suite (golden queries)

SECTION 7 — OBSERVABILITY

  • search latency p50/p95

  • index lag (event time → indexed time)

  • zero-results rate

  • query error rate

  • “fallback to DB” rate

SECTION 8 — EXERCISES

  1. Write your filter semantics (AND/OR, precedence).

  2. Design your indexing pipeline and lag SLO.

  3. Create a UI latency budget and list the techniques you’ll use.

  4. Define a fallback mode when search engine is down.

🏁 END — SEARCH + FILTERING CASE STUDY