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

1. 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.
2. 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).
3. Data model
   • Define schemas for Scenario, Turn/Prompt, UserSession, Attempt, and UserProgress.
   • Describe indexing for fast scenario discovery and session retrieval.
4. 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.
5. Personalization
   • How to adapt difficulty, vocabulary, or pace per user.
   • What signals and features you would log.
6. Scale and reliability
   • Estimate QPS, concurrency, and storage growth.
   • Propose caching, streaming, and backpressure.
   • Handle timeouts, retries, idempotency, and partial failures.
7. Safety and compliance
   • Content moderation, PII handling, data retention, privacy controls, localization.
   • Offline/poor-network considerations.
8. 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

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