Design speaking scenarios and auth/profile API

Q: Design speaking scenarios and auth/profile API

This question evaluates a candidate's ability to design scalable, real-time speaking-practice features and a minimal authentication/profile API, encompassing system architecture, service decomposition, data modeling, ASR/LLM integration, personalization, security and privacy, and operational concerns like scaling and observability.

Q: How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

Q: What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Onsite rounds at Speak.

Q: What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Speak during technical interviews.

Question

System Design Task: Speaking-Scenario Practice Feature + MVP Auth API

Context: You are designing a new speaking-scenario practice capability for a language-learning app (e.g., Speak). Users select real-life scenarios (ordering coffee, job interview), practice by speaking, and receive real-time feedback and scores. You will also design a small MVP authentication/profile API to support the feature.

Part A — Speaking-Scenario Practice Feature

Functional scope
- Let users browse/search/select scenarios; receive prompts; speak responses; get real-time feedback and a score.
- Include progress tracking and the ability to pause and resume sessions.
Architecture
- Propose services/components (e.g., content service, session/orchestration, speech-to-text, LLM feedback, scoring, personalization, analytics).
- Define their APIs and data flow (client ↔ services ↔ data stores).
Data model
- Define schemas for Scenario, Turn/Prompt, UserSession, Attempt, and UserProgress.
- Describe indexing for fast scenario discovery and session retrieval.
LLM/ASR integration
- Choose ASR and feedback-generation models.
- Describe prompt strategy, guardrails, latency targets, token/cost budgets, and fallback behavior when models fail or rate-limit.
Personalization
- How to adapt difficulty, vocabulary, or pace per user.
- What signals and features you would log.
Scale and reliability
- Estimate QPS, concurrency, and storage growth.
- Propose caching, streaming, and backpressure.
- Handle timeouts, retries, idempotency, and partial failures.
Safety and compliance
- Content moderation, PII handling, data retention, privacy controls, localization.
- Offline/poor-network considerations.
Experimentation and metrics
- Define success metrics (learning outcomes, engagement), guardrails, and how to A/B test variations of prompts/feedback.

Part B — MVP API: User Authentication and Profile Management

Endpoints
- Register (email + password)
- Authenticate (login)
- Retrieve profile
- Update profile
- Delete account
- Specify request/response shapes and status codes.
AuthN/Z
- Choose session vs. JWT; token TTL/refresh; secure cookie vs. header usage.
- Describe password hashing (can be mocked) and account lifecycle.
Storage
- Use in-memory data structures for users, sessions/tokens, and profiles.
- Define keys and concurrency handling.
Non-functionals
- Rate limiting, input validation, error handling, idempotency for register/delete, logging, minimal observability.
Constraints
- MVP first, edge cases later; AI tools allowed; optimize for development velocity while maintaining clear, usable APIs.
Evaluation
- Explain trade-offs, data modeling decisions, and how to evolve this into a production-ready service.

Design speaking scenarios and auth/profile API

Quick Overview

System Design Task: Speaking-Scenario Practice Feature + MVP Auth API

Part A — Speaking-Scenario Practice Feature

Part B — MVP API: User Authentication and Profile Management

Solution

Comments (0)