Design a Real-Time Suggestions Service

Quick Overview

Design a Real-Time Suggestions Service evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design a Real-Time Suggestions Service

Company: SoFi

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Design a system that provides real-time typeahead/autocomplete suggestions as users type. Cover API design and request/response schemas, data modeling and indexing (e.g., prefix trees or inverted indexes), ranking signals and personalization, latency targets (e.g., <100 ms P 95), caching layers, scalability, freshness and backfill pipelines, A/B experimentation hooks, and failure handling.

Quick Answer: Design a Real-Time Suggestions Service evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

|Home/System Design/SoFi
SoFi logo
SoFi
Jul 16, 2025, 12:00 AM
hardSoftware EngineerOnsiteSystem Design
14
0

Design a Real-Time Suggestions Service

System Design: Real-Time Typeahead/Autocomplete

Context

Design a real-time typeahead/autocomplete service for a consumer-facing web and mobile application. Users see suggestion updates on each keystroke. Assume global traffic, multiple locales, and both anonymous and signed-in users.

Requirements

Design the system and cover:

  1. API design and request/response schemas
  2. Data modeling and indexing (e.g., prefix trees, FST, inverted indexes)
  3. Ranking signals and personalization
  4. Latency targets and budgets (e.g., P95 < 100 ms)
  5. Caching layers (edge, in-memory, distributed)
  6. Scalability and capacity planning
  7. Freshness and backfill pipelines (batch + streaming)
  8. A/B experimentation hooks and telemetry
  9. Failure handling and graceful degradation

State assumptions where needed and justify trade-offs.

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...