Architect serving and storage for recommender

Last updated: Mar 29, 2026

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.

|Home/System Design/Salesforce

Architect serving and storage for recommender

Salesforce

Aug 1, 2025, 12:00 AM

hardSoftware EngineerTechnical ScreenSystem Design

5

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

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.
Application serving tier
- Multiple stateless application servers behind a reverse proxy/load balancer.
- Horizontal scalability, health checks, autoscaling.
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.
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.
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.
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.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask

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

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

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

Your design canvas — auto-saved