Viraj Thakur

You are in a system design interview at Amazon for an SDE-3 role and the interviewer has given you the question to Design Netflix. He then asks a follow up to you: How does Netflix knows when to show: Are you still watching? Is it just time-based? If it were time-based, you would see it every time. So what is actually going on under the hood? Both look like a simple pop-up. Underneath, it is a mix of product thinking, client logic, and backend events. Btw, if you’re preparing for system design/coding interviews, check out our mock interview tool. You can use it for free here: https://lnkd.in/gpCn7t2T [1] Start from the product goals The feature is not only about nagging people. - Save bandwidth and CDN cost if the viewer has slept or walked away - Avoid autoplaying potentially sensitive content in an empty room - Protect kids if parents start a show and leave the TV on - Do all this without annoying active binge watchers So the design must answer one question: "When is the user probably not here any more" [2] Naive design - pure timer Simplest idea: - If playback has been running for 2 hours, show Are you still watching - If user clicks "Yes", reset the timer Why this is weak: - Someone can binge 5 episodes in a row and gets interrupted in the middle of an intense scene - Someone can start a show, walk away after 5 minutes, and the platform will keep streaming for the next 2 hours - It ignores how many episodes were auto played, device type, time of day, user habits  [3] Realistic design - session and engagement signals Think in terms of a "watch session" and "engagement events". Signals the client can track: - Play, pause, seek, volume change - Episode finished and next episode auto started - Remote or keyboard input, UI navigation - Screen on or off events from the device - For mobiles: app background or locked state A common heuristic could be: - Count how many episodes have auto played without any user interaction - Track how long it has been since the last button press or navigation - Only trigger the prompt when both are high enough Example rule: - If 3 episodes in a row have auto played - And there has been no interaction for 45 minutes - Then, before starting episode 4, show Are you still watching This feels much smarter: - Active viewers who pause, skip intro, change volume keep resetting the "engagement clock" - Sleeping viewers do not touch anything, so the next episode is blocked by the prompt  [4] Client heavy vs server heavy design You can talk about two design choices. Client first: - All logic runs inside the app on TV, mobile, or web - Client keeps an in memory session model and decides when to show the popup - It still sends telemetry events to backend for analytics and future tuning Pros: - Works even with flaky network - Highly responsive, no extra server round trip Cons: - Logic must be implemented and updated across many platforms - Harder to quickly roll out rule changes Continued ↓

184

12 Comments

System Design interviews don’t reward memorization. They reward clarity. Because today, system design is no longer “for seniors only.” Even SDE1/SDE2 interviews test whether you can think at scale - users, latency, failures, cost, and reliability. That’s exactly what this guide covers. It breaks down 10 must-know system design architectures that show up again and again in interviews - along with the core components, scaling tricks, and the exact “interview gold points” for each system. Instead of random theory, it trains you to explain systems like an engineer. How requests flow, where bottlenecks happen, what components matter most, and what tradeoffs interviewers actually care about. The 10 Designs Covered Inside : 1. It starts with fundamentals like a URL Shortener - then expands into real-world architectures like: 2. A Messaging System (WhatsApp) that handles delivery, retries, ordering, read receipts, and offline users. 3. An Instagram Feed that teaches fanout-on-write vs fanout-on-read and ranking tradeoffs. 4. A Video Streaming system (YouTube/Netflix) that shows the encoding pipeline, chunking, and why CDNs dominate scale. 5. A Ride Sharing system (Uber) built on real-time GPS streams, ETA accuracy, and geospatial indexing. 6. A Web Crawler (Google) designed as a pipeline: discover → fetch → parse → index with deduplication. 7. An E-commerce system (Amazon) showing inventory consistency, idempotent orders, and event-driven flows. 8. A Food Delivery system powered by workflow engines and state machines for reliable tracking. 9. A Spotify architecture where streaming + personalization becomes the retention engine. 10. And a Dropbox file sharing system where metadata + versioning is the real product. If you can explain these 10 clearly, you’re already ahead of most candidates - because these designs cover almost every interview pattern: caching, queues, sharding, consistency, fanout, CDN, state machines, and observability.

410

73 Comments

Stop treating Load Balancers and Reverse Proxies as the same thing. In System Design interviews (and production incidents), the distinction matters more than you think. As we move from SDE1 to SDE2, we stop asking "How do I make this code work?" and start asking "How does this system scale and survive failure?" Here is the deep dive on two critical components that often get conflated. 1. The Load Balancer (The Scaler) Primary Goal: Availability & Horizontal Scaling. The Job: Spreading traffic across multiple compute resources to eliminate Single Points of Failure (SPOF). The SDE2 Nuance: You need to know the difference between Layer 4 (Transport) and Layer 7 (Application) balancing. L4 is fast; it forwards packets based on IP/Port without looking inside. L7 is smart; it terminates the connection, reads the HTTP headers/path, and routes /api differently than /images. 2. The Reverse Proxy (The Shield) Primary Goal: Security, Unification & Offloading. The Job: Sitting in front of backend servers to hide their topology and IP addresses. The SDE2 Nuance: SSL Termination. Decrypting HTTPS handshakes is CPU-intensive. A Reverse Proxy handles this heavy lifting at the edge, allowing your backend application servers to focus purely on business logic (and communicate via HTTP inside the private VPC). The Reality Check 💡 In modern architecture (and cloud environments like AWS ALB or tools like NGINX), the lines blur. We often use a single component to perform both roles simultaneously—terminating SSL (Reverse Proxy) and then distributing the request to a pool of instances (Load Balancer). But knowing which function you are tuning—and why—is what separates a mid-level engineer from a senior one. Questions for the network: Do you prefer handling SSL termination at the Load Balancer level or strictly on the application server for end-to-end encryption? #SystemDesign #SDE2 #SoftwareEngineering #Scalability #DistributedSystems #DevOps

66

1 Comment

Is CDN a reverse proxy, just like a load balancer or an API gateway? Yes. While LB and API gateway fit the classic definition of a Reverse Proxy, CDN is also a reverse proxy with caching as its primary purpose. Like any other reverse proxy, 1. CDN acts as a single point of entry for client requests, 2. CDN abstracts out different origins configured behind it 3. CDN can also route the requests across multiple origins depending on the route-matching configuration. Hence, the deduction is on point, and LB, API Gateway, and CDN are all examples of Reverse Proxies. I elaborated on CDN, as it is an unconventional example. ps: I love how the comments on my YouTube videos are also no-fluff and filled with thought-provoking questions. Thank you for asking such great questions. By the way, the question was asked in my recent video on Forward and Reverse Proxy. In the video, I went into highly practical details with real-world examples and stories from my life. give it a watch and subscribe - youtu.be/HrG0MHkSsCA btw, enrollments open for sys design June cohort, about 30 seats left - arpitbhayani.me/course

324

8 Comments

If you have system design interview at Amazon for a senior SWE role. And need a quick 2 minute refresher on Microservices, Read this : Microservices isn't one skill. It's 20 deliberate progressions. 𝗕𝗔𝗦𝗜𝗖 (𝟭-𝟳) 1. 𝗪𝗵𝗮𝘁 𝗔𝗿𝗲 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀     Independent services working together as one system. 2. 𝗠𝗼𝗻𝗼𝗹𝗶𝘁𝗵 𝘃𝘀 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀     Understand differences. Know when microservices enhance scalability. 3. 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗕𝗮𝘀𝗶𝗰𝘀     Learn HTTP, RPC, and messaging fundamentals for service interaction. 4. 𝗥𝗘𝗦𝗧𝗳𝘂𝗹 𝗔𝗣𝗜𝘀     Design stateless REST endpoints for structured communication. 5. 𝗴𝗥𝗣𝗖 & 𝗣𝗿𝗼𝘁𝗼𝗯𝘂𝗳     Use high-performance communication through binary Protobuf serialization. 6. 𝗔𝗣𝗜 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻     Secure APIs using OAuth2, JWT tokens, and standard auth methods. 7. 𝗔𝗣𝗜 𝗚𝗮𝘁𝗲𝘄𝗮𝘆     Central gateway manages routing, authentication, and unified access. 𝗜𝗡𝗧𝗘𝗥𝗠𝗘𝗗𝗜𝗔𝗧𝗘 (𝟴-𝟭𝟰) 8. 𝗖𝗲𝗻𝘁𝗿𝗮𝗹𝗶𝘇𝗲𝗱 𝗖𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻   Ensure consistent behavior across distributed services. 9. 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 𝗗𝗶𝘀𝗰𝗼𝘃𝗲𝗿     Automatically locate service instances without manual configuration. 10. 𝗟𝗼𝗮𝗱 𝗕𝗮𝗹𝗮𝗻𝗰𝗶𝗻𝗴     Distribute traffic evenly across service nodes. 11. 𝗖𝗶𝗿𝗰𝘂𝗶𝘁 𝗕𝗿𝗲𝗮𝗸𝗲𝗿 𝗣𝗮𝘁𝘁𝗲𝗿𝗻     Prevent cascading failures using fallback logic. 12. 𝗠𝗲𝘀𝘀𝗮𝗴𝗲 𝗤𝘂𝗲𝘂𝗲𝘀     Enable asynchronous communication with message brokers. 13. 𝗗𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱 𝗧𝗿𝗮𝗰𝗶𝗻𝗴     Trace service requests end-to-end clearly. 14. 𝗟𝗼𝗴𝗴𝗶𝗻𝗴 & 𝗠𝗼𝗻𝗶𝘁𝗼𝗿𝗶𝗻𝗴     Track metrics and logs using dashboards. 𝗔𝗗𝗩𝗔𝗡𝗖𝗘𝗗 (𝟭𝟱-𝟮𝟬) 15. 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗽𝗲𝗿 𝗦𝗲𝗿𝘃𝗶𝗰𝗲     Each service uses its own database. 16. 𝗦𝗮𝗴𝗮 𝗣𝗮𝘁𝘁𝗲𝗿𝗻     Coordinate distributed transactions across services. 17. 𝗘𝘃𝗲𝗻𝘁 𝗦𝗼𝘂𝗿𝗰𝗶𝗻𝗴     Store changes as events for reconstruction. 18. 𝗙𝗮𝘂𝗹𝘁 𝗧𝗼𝗹𝗲𝗿𝗮𝗻𝗰𝗲 & 𝗥𝗲𝘀𝗶𝗹𝗶𝗲𝗻𝗰𝗲     Design for failure with retries, redundancy, and health checks. 19. 𝗦𝗰𝗮𝗹𝗶𝗻𝗴 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀     Auto-scale services independently based on traffic. 20. 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 & 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆     Use Kubernetes, Docker, and dashboards for automated rollouts. You don't climb this by reading blog posts. You climb it by building. Breaking. Fixing. Defending your decisions. Follow Rakshith Yadhav  for • real-world engineering insights. • practical system design frameworks • lessons from building scalable AI systems.

251

43 Comments

In India, Blinkit handles approximately 1.7 million deliveries per day, often with a delivery window of 10 minutes. Here is a quick look at their tech stack, which made things possible for them. Redis is being used as an in-memory datastore for distributed locking, which is enabling optimistic locking at scale. https://lnkd.in/g6QrYJw5 #Redis #Blinkit #Ecommerce #DistributedLocking #Realtimesystems

24

FAANG companies are great. But not all great companies are FAANG companies. There are plenty of product companies that: - Pay really well - Build serious tech -And work on problems that are as hard, sometimes harder Here are some names you should at least know and research: Fintech: 1. Razorpay 2. PhonePe 3. CRED 4. Zerodha 5. Groww 6. Slice 7. Juspay SaaS and devtools: 8. Postman 9. BrowserStack 10. Freshworks 11. Zoho 12. Chargebee 13. Hasura 14. LambdaTest 15. CleverTap 16. MoEngage Consumer, marketplaces, product-heavy: 17. Flipkart 18. Swiggy 19. Zomato 20. Zepto 21. Meesho 22. BigBasket 23. Udaan Global product teams with strong eng offices here: 25. Intuit 26. Atlassian 27. Adobe 28. Salesforce 29. SAP Labs 30. Walmart Global Tech 31. Target Tech 32. Uber Global SaaS and analytics: 33. Rippling 34. Deliveroo 35. Snowflake 36. Databricks 37. Cloudflare 38. Datadog 39. Twilio 40. Nielsen

351

13 Comments

A candidate interviewing for SSE @ Google was asked to break down the design of Google Drive. Another candidate who was interviewing for the role of SDE-III @ Amazon, was asked another with a file upload system question. I’ve faced these too. System design rounds love “simple” file upload questions until you add one layer of complexity: – Add virus scanning? Whole new security headache. –  Add multi-region storage? Now you’re fighting replication and consistency. –  Add instant previews or image compression? Welcome to async pipelines and job queues. Here’s my personal checklist of 15 things you must get right when building file upload systems: 1. Never upload directly to your backend → Use presigned URLs so files go straight to S3, GCS, or your object storage, offloading bandwidth and freeing up backend resources. 2. Validate file type by content, not extension → Don't trust “.jpg” or “.pdf”, read the file’s magic bytes or headers to catch disguised executables or corrupted files. 3. Set strict file size limits (early) → Prevent memory blowups, denial of service, and accidental 50GB “cat video” uploads. 4. Multipart/chunked uploads for large files → Upload big files in chunks, so you can retry failed pieces, resume partial uploads, and never lose user progress. 5. Resumable uploads matter → User’s WiFi dies? Don’t make them start from scratch. Store upload progress, support resume tokens. 6. Async virus scanning before “marking ready” → Queue the scan; don’t let user-access or public-sharing happen until the result is clean. 7. Never trust user-supplied metadata → Recompute MIME types, image dimensions, video duration, etc., server-side, attackers will fake everything. 8. Expire unused presigned URLs fast → Every upload/download link should expire in minutes, not days. Stops replay attacks and stale-link leaks. 9. Background post-processing → Thumbnails, transcoding, compression, indexing, all should be async jobs, not blocking the upload. 10. Signed download URLs only  → Never expose raw S3 or GCS paths. Every download link should be time-bound and permission-checked. 11. Enforce per-user and per-IP rate limits → Throttle abusive clients, prevent brute force, and stop sudden spikes from melting your backend. 12. Encrypt files at rest (and in transit)  → Use server-side encryption (SSE) on S3 or GCS, plus HTTPS/TLS for every file transfer. 13. Version every upload → Store new files with unique IDs or version suffixes, never overwrite by default. Enables “undo” and rollback, and prevents race conditions. 14. Log every upload and access → Audit logs for every file action: who uploaded, who accessed, when, and from where. Critical for debugging and compliance. 15. Handle storage failures and edge cases gracefully → What happens if S3 times out? What if storage quota is exceeded? Handle partial failures, show clear errors, and keep users in the loop. Feel free to reach out to me: https://lnkd.in/guttEuU7

2,081

73 Comments