Architect serving and storage for recommender

Quick Overview

Architect serving and storage for recommender 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.

Architect serving and storage for recommender

Company: Salesforce

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Design the serving and data infrastructure for a recommendation service. Cover client data fetching and API design, multiple stateless application servers behind a reverse proxy/load balancer, caching, and latency targets. Detail storage schemas for users, items, and interaction logs (user_id, item_id, signal, timestamp), indexing/partitioning strategies, how batch training reads and online serving writes/reads coexist, and approaches to scaling, consistency, and fault tolerance.

Quick Answer: Architect serving and storage for recommender 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/Salesforce
Salesforce logo
Salesforce
Aug 1, 2025, 12:00 AM
hardSoftware EngineerTechnical ScreenSystem Design
7
0

Architect serving and storage for recommender

System Design: Recommendation Service (Serving + Data Infrastructure)

Context

Design a production-ready recommendation service for a large-scale consumer app. The service should return personalized item recommendations with strict latency SLOs and support continuous model training. Assume millions of users and items, peak thousands of RPS, and multi-region deployment. The design should cover both online serving and offline/batch ML workflows.

Requirements

  1. Client data fetching and API design
    • Public, versioned API for fetching recommendations.
    • Logging of user interactions (e.g., view, click, add-to-cart) for training and real-time adaptation.
    • Caching semantics and idempotency where appropriate.
  2. Application serving tier
    • Multiple stateless application servers behind a reverse proxy/load balancer.
    • Horizontal scalability, health checks, autoscaling.
  3. Caching and latency targets
    • Multi-layer caching strategy (client/edge, mid-tier, feature/model caches).
    • Specify end-to-end latency targets (p50/p95), and a latency budget per component.
  4. Storage schemas and data modeling
    • Schemas for users, items, and interaction logs with fields: user_id, item_id, signal, timestamp.
    • Indexing and partitioning strategies for OLTP and OLAP.
  5. Offline/online coexistence
    • How batch training reads the historical data.
    • How online serving performs low-latency reads and writes, including near-real-time feature updates.
    • Strategies to ensure feature parity between offline and online environments.
  6. Scaling, consistency, and fault tolerance
    • Sharding, replication, and multi-region considerations.
    • Consistency choices (strong vs eventual), read-your-writes where needed.
    • Fault isolation, retries, circuit breakers, fallbacks, and degraded modes.

Provide a clear, componentized architecture and justify key 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...

Browse More Questions

More System Design•More Salesforce•More Software Engineer•Salesforce Software Engineer•Salesforce System Design•Software Engineer System Design