Debapriya Das

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

Last 48 hours = pure debugging madness. Our app was randomly failing. Auth breaking. API calls timing out. Edge functions not responding. At first, we thought: Supabase outage? SSL issue? Region latency problem? Nope. Turns out : if a user is on Jio all *.supabase.co domains are resolving to a Jio-owned IP (49.44.79.236) instead of AWS. Which basically means: Your Supabase backend is unreachable. Not slow. Not degraded. Just… dead. What’s wild: supabase.com loads fine App works perfectly on Airtel / Vi Works instantly on VPN Only supabase.co (project API domains) are affected nslookup → wrong IP curl → timeout traceroute → dies inside Reliance network This isn’t a project bug. This isn’t a code bug. This isn’t even a Supabase bug. It looks like DNS-level blocking inside Jio’s network. If you're building for India, this is scary. Because you won’t see a crash. You’ll just see: Drop in signups OTP failures Random API errors Users ghosting mid-flow And you’ll assume it’s your funnel. Given how big Jio’s user base is, this could impact a massive chunk of Indian traffic without founders even realizing it. and to save your time I believe that Jio appears to be DNS-poisoning *.supabase.co to a sinkhole IP and Changing DNS to 1.1.1.1 or 8.8.8.8 alone did not help us. Guys please suggest Temporary workarounds: Except using VPN as cloudflare and Proton vpn didnot work as well for me. If you’re using Supabase and targeting Indian users, please test your app specifically on Jio broadband + Jio mobile data. This kind of infra issue is the worst kind ,silent and invisible. Would love to know if other builders are seeing the same thing. #Supabase #StartupIndia #DevLife #BuildInPublic #SaaS #IndiaTech

15

Here’s exactly how I would crack a $150K+ SWE job at Microsoft in 6 months. (A real strategy my client used to land interviews at Microsoft, Meta, and Stripe) Too many engineers prepare hard to crack MAANG. But they lack a solid strategy. Here’s the exact roadmap I'll follow if I wanted to land a SWE job at Microsoft. Step 1: Resume + Role Clarity → Reverse-engineer the JD Study at least 10+ Microsoft SWE job listings. Highlight recurring keywords, must-haves, and preferred tools. → Rewrite your resume like a product pitch Show measurable impact: Good: “Improved load time by 43%” Bad: “Worked on performance optimization.” → Make it keyword-optimized for ATS without sounding robotic. Step 2: Master DSA the Microsoft Way → Focus on patterns, not problems Microsoft LOVES: Sliding window Trees (esp. DFS/BFS) Graphs Dynamic programming → Suggested Platforms: Leetcode (Microsoft tag), Neetcode(dot)io roadmap, Grokking series on Educative → 2 problems/day + 1 mock interview/week = compounding prep Step 3: System Design (yes, even for junior roles) → Start with High-Level Design (HLD): Learn how to design APIs, caching, rate limiting, and DB scaling. → Build a project where you actually implement what you learn. Step 4: Microsoft-Specific Behavioral Prep → Microsoft uses structured behavioral interviews Focus on “3As” framework: Action → Approach → Aftermath → Use real projects to show: Collaboration Adaptability Customer focus Engineering rigor → Prep 8–10 STAR stories mapped to their values Step 5: Mock + Real-World Practice → Do 4–5 peer or mentor-led mock interviews (especially for behavioral + design) → Record yourself. Watch for filler words, unstructured answers, lack of metrics. → Apply for 5 roles/week—Microsoft + similar-sized companies (to get into interview flow) Step 6: Apply Strategically + Use Referrals → Connect with 3–5 engineers/recruiters/week on LinkedIn. Don’t ask for a referral right away - engage first. → Reach out using tailored messages like: “Hi [Name], I’ve been preparing for an SWE role at Microsoft. Your journey from [X] to [Microsoft] really stood out. If you're open, I’d love to learn more about your experience.” → Submit applications using referrals whenever possible + 1-click apply where relevant The client who followed this playbook now works at Microsoft Azure and had 3 competing offers before accepting. It’s not about doing everything. It’s about doing the right things in the right order. Give yourself 6 months and follow this roadmap to make it a reality. Share this with someone who dreams of working at Microsoft. P.S. Follow me if you are a job seeker in the U.S. I share practical advice that gets you land $150k+ roles in top companies.

97

Most CS engineers in India are effectively useless for Day 1 impact. — One of the biggest reasons we started Polaris School of Technology was to solve a problem that we ourselves faced internally at Classplus Back in 2018, we were building SaaS, and needed software devs, obviously. Easiest call was to go for fresher CS grads - they are young energy + agile learning + early stage cos can afford only them But the shock of our lives, almost no fresher we hired could push live code on day 1. And the simplest explanation - "we didn’t learn how to do this in college."   And on asking why did they not - "Nobody exactly told us how to do so."    And max kids just prepared some puzzles on internet to crack campus placements. Funny max! — And this was not just with us, almost every tech founder we know was facing the same.    Resulting in two options: One, abandon and only go for senior talent, but non-feasible for the costs + org structure involved Two, train and upskill the fresh talent and make them industry-relevant over 6-9 months and see them contribute meaningfully post that. Each, every, and 100% of the founders I know in life opted for the second one, and the first jobs for most software engineers became the playground where they learnt all their coding skills. The bar was so low to be honest, that anyone who had done a couple of good internships / built some functional products / written actual code during college times was getting 2x CTCs than others. The sad part: All of this is still true in most cases. Most CS grads actually learn real coding / software development on the go, gradually rising through the skills + payscale. And this pushes back everyone - startups lose time in building products / engineers lose some of their sharpest years / the ecosystem moves slower than it should. — And that’s why we built Polaris with a lot of heart. Not just coz we find it worthy, but also because the industry needs this. Young CS grads who interact with real companies while studying, build live products, do a few internships, network with existing devs, participate in a few hackathons, and have enough confidence / clarity before they step in full-time. No training wheels. No "6-month ramp-up." Just Day 1 ready :)

246

12 Comments

Just read about a company whose ex-employee deleted all their Github repos and AWS infra, basically wiped everything. Brutal, but honestly, not surprising. Most Indian startups (and even bigger tech companies) run exactly like this: zero basic security, everyone has admin access and ex-employee access is rarely revoked. Disaster Recovery? Forget DR, even the basics are missing. Here is the harsh reality, if you are running things this way, you are basically asking for it. Seen this happen way too many times. So here is my no-BS checklist to avoid being that headline: - Zero Trust, always: Nobody gets access by default. Only give what’s needed, nothing more. - 2FA everywhere: No excuses. - Limit codebase access: Engineers should see only what they’re building, not the whole farm. - Enable deletion protection: Github, AWS, GCP... everyone gives you this option. Switch it on. - Admin lockdown: Have just one or max two admins. Root accounts? Never use them for daily ops, keep them locked up. - Password managers are a must: Just use 1Password, LastPass, whatever, stop sharing passwords on Slack or WhatsApp. - Go for SSO plans: Link everything to Google or Microsoft. When someone leaves, you kill the email, and poof...access is gone everywhere. - If you can afford it, use Okta or upgrade your Google Workspace to Enterprise (Vault is a lifesaver for legal/data recovery). Better safe than sorry. - For Google Drive/docs, don’t make individual employees owners. Use Shared Drives (Google Workspace Business/Enterprise), or set up a company account as the owner for all important docs. Bottom line: you will need to spend a bit more, but the price of getting wiped out is way, way higher. There are smarter ways, but even if you just do this much, you will sleep a lot better at night.

76

9 Comments