## Notes System design interviews tend to follow a structure 1. Understand and ask questions to clarify features and requirements 2. Design high-level that satisfies requirements 3. Deeper dive with additional requirements 4. Q&A ## Understand Ask questions to understand core features and non-functional requirements. ## Initial Design - API Design - Start a top-down approach by defining APIs - Use HTTP verbs, URLs, inputs, and responses - Start with a load balancer - [[#High-Level Design Blueprint]] - Don't dive deeply into databases (yet) - Data models and schemas - Specify data access patterns - Discuss read/write ratio - Discuss database options - Discuss indexing options ### High-Level Design Blueprint This is a diagram ![[Screenshot 2024-10-04 at 20.54.56.png]] ## Deeper Dive 1. Articulate the problem - Scale - Performance - Accuracy - Freshness - Consistency - Security 2. Come up with at least two solutions 3. Discuss trade-offs with estimated numbers - As the following for databases - Scaling - Concurrency - Failure scenarios ## Wrapping Up - Reiterate what was designed ## Appendix ### Non-functional Requirements Senior engineers should also understand "non-functional" requirements. These "non-functional" requirements are back-of-napkin estimations for List reasons for particular technology choices. ### WebSockets WebSocket APIs tend to be stateful and are hard to scale. Scaling would be appropriate for the [[#Deeper Dive]]. ## References - [System Design Interview Steps - YouTube](https://www.youtube.com/watch?v=i7twT3x5yv8)