https://systemdesignschool.io/resource-estimator
- Scalability: https://lnkd.in/gPGhW-qK
- Availability: https://lnkd.in/gQk2p4_6
- CAP Theorem: https://lnkd.in/g_tFqJJb
- SPOF: https://lnkd.in/gw_uHZWn
- Consistent Hashing: https://lnkd.in/gR9wFDpz
- Load Balancers: https://lnkd.in/dzM7VDKq
- Load Balancing Algorithm: https://lnkd.in/gvxfwEUr
- Caching: https://lnkd.in/gBSeTstS
- Caching Strategies: https://lnkd.in/dVk7nZ_Y
- Cache Eviction Strategies: https://lnkd.in/gQAEXEmq
- Distributed Caching: https://lnkd.in/gf6pCqdi
- CDNs: https://lnkd.in/g2zvPhkA
- Database Types: https://lnkd.in/gDxtZVE2
- SQL vs NoSQL: https://lnkd.in/gHyC9qWc
- ACID Transactions: https://lnkd.in/dB3QHiMz
- Database Indexes: https://lnkd.in/g_-bQWtA
- Database Sharding: https://lnkd.in/g9mc-d5m
- Database Scaling: https://lnkd.in/gSUtAwc7
- APIs: https://lnkd.in/dsbwPZ6N
- API Gateway: https://lnkd.in/gtyXmvf4
- WebSockets: https://lnkd.in/gD-TUZep
- Message Queues: https://lnkd.in/g-jnNGDC
- Service Discovery: https://lnkd.in/gRj_QeP8
- Bloom Filters: https://lnkd.in/gfGjCrSZ
- Rate Limiting Algorithms: https://lnkd.in/gYDxg8XY
- Idempotency: https://lnkd.in/gDB3AJij
- Concurrency vs Parallelism: https://lnkd.in/gGZXhjBD
- Proxy vs Reverse Proxy: https://lnkd.in/gMTtidBq
- Batch vs Stream Processing: https://lnkd.in/gKtj_qWh
- Stateful vs Stateless Architecture: https://lnkd.in/gz_ccK-Y
- Clarify both functional and non-functional requirements before designing.
- Assume everything can and will fail. Make it fault tolerant.
- Don't add functionality until it's necessary. Avoid over-engineering.
- There is no perfect solution. It’s all about tradeoffs.
- Prefer horizontal scaling over vertical scaling for scalability.
- Use load balancers to distribute traffic and ensure high availability.
- Consider using SQL databases for structured data and ACID transactions.
- Opt for NoSQL databases when dealing with unstructured data.
- Use database sharding to scale SQL databases horizontally.
- Use database indexing to optimize read queries.
- Use rate limiting to prevent system overload and DOS attacks.
- Use websockets for real-time communication.
- Employ heartbeats / health checks for failure detection.
- Consider using a message queue for asynchronous communication.
- Implement data partitioning and sharding for large datasets.
- Consider denormalizing databases for read-heavy workloads.
- Consider using event-driven architecture for decoupled systems.
- Use CDNs to reduce latency for a global user base.
- Use write-through cache for write-heavy applications.
- Use read-through cache for read-heavy applications.
- Use blob storage to store media files like files, images, videos etc..
- Implement data replication and redundancy to avoid single point of failures.
- Implement autoscaling to handle traffic spikes smoothly.
- Use asynchronous processing to run non-urgent/background tasks.
- Make operations idempotent where possible to simplify retry logic and error handling.
- Prefer microservices architecture over monoliths for scalability, modularity, and maintainability.
- Consider using an API gateway when you have multiple microservices.
- Use the circuit breaker pattern to prevent cascading failures
- Design clear and consistent APIs and incorporate security.
- Consider using a data lake or data warehouse for analytics and reporting.
- Video streaming services like Netflix: https://lnkd.in/gnHSyCj8
- Autocomplete feature of Google: https://lnkd.in/g3VFcaYN
- Proximity service like Uber: https://lnkd.in/grtPbr6k
- Hotel booking services like Airbnb: https://lnkd.in/gWjrGwCM
- File sharing service like Dropbox: https://lnkd.in/gnSQ6rAd
- Web crawler: https://lnkd.in/gTkfCH8U
- Social media apps like Twitter: https://lnkd.in/guParNhY
- Messaging app like WhatsApp: https://lnkd.in/g5zJa_4W
- Online document editor like Google Docs: https://lnkd.in/gBvztEqV
- URL shortener or TinyURL: https://lnkd.in/gJPWZsX3
- Notifcation Service
- Designing Data Intensive Application
- Amazon : Dynamo DB paper
- Data Structures behing DataBases
- Grokking System Design Interview
Book : https://github.com/VaspulaVijayaLakshmi/System-Design/tree/main/Books
TradeOffs : https://blog.algomaster.io/p/system-design-top-15-trade-offs
Design Problems and template : https://systemdesignschool.io/primer#master-template
HLD : REVISION BOOK https://github.com/VaspulaVijayaLakshmi/System-Design/blob/main/Algomasterio_System_Design_Interview_Handbook.pdf
HLD : https://blog.algomaster.io/archive?sort=top https://github.com/karanpratapsingh/system-design
KAFKA : https://github.com/VaspulaVijayaLakshmi/System-Design/blob/main/KAFKA/README.md
GRAPHQL : https://github.com/VaspulaVijayaLakshmi/System-Design/blob/main/GraphQL.md
SHA → Secure Hash Algorithm MD5 → Message Digest 5
Both are hashing algorithms, but:
-> MD5 is older, produces a 128-bit hash, and is considered broken (collisions possible).
-> SHA is a family of algorithms (SHA-1, SHA-2, SHA-3, etc.), more secure, widely used in digital signatures, TLS, blockchain, etc.
Locks :
Distributed lock with a TTL (Time To Live) using a distributed system like Redis. Redis is an in-memory data store that supports distributed locks and is well-suited for high-concurrency environments.
It offers high availability and can be used to implement a distributed lock mechanism for the ticket booking process.
Here is how it would work:
When a user selects a ticket, acquire a lock in Redis using a unique identifier (e.g., ticket ID) with a predefined TTL (Time To Live). This TTL acts as an automatic expiration time for the lock.
If the user completes the purchase, the ticket's status in the database is updated to "Booked", and the lock in Redis is manually released by the application after the TTL.
If the TTL expires (indicating the user did not complete the purchase in time), Redis automatically releases the lock. This ensures that the ticket becomes available for booking by other users without any additional intervention.
https://www.hellointerview.com/learn/system-design/deep-dives/redis
Back of the Envelope Calculations
| Power of 10 | Number Name | Storage Equivalent | Scientific Notation |
|---|---|---|---|
| 10 | 1 Thousand | 1 Kilobyte (KB) | 10³ |
| 10 | 1 Million | 1 Megabyte (MB) | 10⁶ |
| 10 | 1 Billion | 1 Gigabyte (GB) | 10⁹ |
| 10 | 1 Trillion | 1 Terabyte (TB) | 10¹² |
| 10 | 1 Quadrillion | 1 Petabyte (PB) | 10¹⁵ |
- Practice a question from every major pattern (not just one type!): • Social networks (news feed, messaging, notifications) • Streaming/content delivery (video, live data) • E-commerce (shopping cart, inventory) • Cloud storage/file sharing • Location-based services • Ticketing/booking platforms • Leaderboards, collaborative tools, rate limiters
- Do at least one “foundational component” (cache, queue, rate limiter, etc.)
How to Approach the Interview
- Clarify requirements: Never assume, always discuss users, scale, features, constraints
- Diagram a simple, functional system -before- optimizing or deep-diving
- Prioritize the most “interviewer-interesting” part for deep dive (scaling, bottleneck, or reliability)
- Clearly explain tradeoffs (what do you gain/lose with each approach?)
- Make decisions, don’t just list options; pick, then justify
Narrate your thinking like a tech lead explaining to a junior engineer
- Engage the interviewer, treat it as collaborative problem solving, not a solo show
- Welcome interruptions, questions, and redirection, don’t ignore hints or suggestions
Pick a system design framework and practice it until it feels natural
- Always start by gathering -all- requirements (functional + non-functional)
- Clarify ambiguities, ask the interviewer questions up front
- List core entities and APIs before designing anything
- Don’t chase a perfect design, opt for something that “works and can be improved”
Difference b/w locking and Isolation
- Locking - control concurrent transactions
- Isolation Levels - Controls visibility of data between transactions
➤ 𝐄𝐚𝐬𝐲
- Design Parking Garage
- Design Vending Machine
- Design Distributed Cache
- Design an Authentication System
- Design Distributed Job Scheduler
- Design Distributed Key-Value Store
- Design a URL Shortener like TinyURL
- Design Content Delivery Network (CDN)
- Design a Text Storage Service like Pastebin
- Design Unified Payments Interface (UPI)
➤ 𝐌𝐞𝐝𝐢𝐮𝐦 11. Design Tinder 12. Design Twitter 13. Design Reddit 14. Design Netflix 15. Design Spotify 16. Design TikTok 17. Design Shopify 18. Design YouTube 19. Design Facebook 20. Design WhatsApp 21. Design Instagram 22. Design Rate Limiter 23. Design Google Search 24. Design a Payment System 26. Design Online Code Editor 27. Design Notification Service 28. Design Flight Booking System 29. Design Stock Exchange System 30. Design an E-commerce Store like Amazon 31. Design Autocomplete for Search Engines 32. Design a Distributed Message Queue like Kafka 33. Design an Analytics Platform (Metrics & Logging)
➤ 𝐇𝐚𝐫𝐝 34. Design Uber 35. Design Zoom 36. Design Google Docs 37. Design Google Maps 38. Design a Distributed Web Crawler 39. Design Code Deployment System 40. Design Distributed Locking Service 41. Design File Sharing System like Dropbox 42. Design a Food Delivery App like DoorDash 43. Design Location-Based Services like Yelp 44. Design Distributed Cloud Storage like S3 45. Design a Ticket Booking System like BookMyShow