Kaushal Kumar

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

Prakhar's HLD for Dropbox's files and folders sharing Prakhar sharing a folder 1. Prakhar right-clicks his "Project Alpha" folder and invites his colleague, Simran, granting her "edit" access     2. His client sends a request to the Share Service to define rules     3. Creating the Share 1. Share Service creates a unique, shared record with File/folder identifier, Access level (view/edit), Recipient email (Simran), Expiration settings (if any) 2. It attaches an Access Control List (ACL) to shared record, marking Prakhar as the owner and adding Simran as an editor 4. Creating a "Link" 1. Share Service contacts with Metadata Service to place a special pointer, like a shortcut or a symbolic link, inside Simran's file directory 2. Pointer points to the shared record     5. Invitation: A notification is sent to Simran. She clicks "Accept" Simran seeing the Folder 1. No Data Duplication: When Simran accepts, we don't copy all of Prakhar's files to her account     2. Instant Appearance 1. The next time Simran's device syncs, it fetches her file list 2. Metadata Service sees the pointer and seamlessly includes the contents of "Project Alpha" 3. The folder appears instantly on her device, with zero file data downloaded yet 🤔 over to you, what are benefits of "mount point" approach? Let me know in the comments! 👇 📣 Join 7-day email course to effectively optimize 60-minute system design interview - https://lnkd.in/gDBzCnE3 

48

16 Comments

Booking(dot)com increased >250,000,000 Reviews backend hardware by 50% Handling ~10,000 req / sec, maintaining p99 of < 50ms Background Review data is partitioned across several shards, with property ID as partitioning Key Entire system is replicated across several availability zones Problem Changing the number of shards means the keys will be redistributed across the remaining shards. if the routing layer tries to resolve the shard ID (of a given accommodation) during the ongoing resharding, it would not be able to resolve the location Solution - They build a service using "Consistent Hash Algorithm by John Lamping, Eric Veach" that ensures randomly distributed data and allows for scaling in both directions by moving bare minimum data around shards - The property that makes it possible is Monotonicity that means data can only be transferred from old shards to new shards during an ongoing resharding. (no unnecessary rearrangement) - Until the new shards have fully loaded the reassigned keys, nodes of our routing layer are only aware of the old scheme and route traffic only to the old shards - After new shards have loaded reassigned keys, some of the coordinators were made aware of the new sharding scheme - After all traffic is routed to the new scheme, old shards are updated to stop loading keys that were reassigned to new shards. - The algorithm is fast (nanoseconds) and has no additional storage requirements 🤔 over to you, how they predicted future hardware requirements Let me know in the comments! 👇 --- You've got System Design skills but showcasing them in 60 minutes interview is a completely different challenge for e.g. where to start? How much time to spend on HLD vs LLD etc Let me share a FREE 7-day email course that provides a step-by-step framework for acing your 60-minute System Design interview 📣 Join 2200+ subscribers and sign up for the course to learn time allocation to demonstrate full range of design skills (link in comments 👇)

100

14 Comments

Don’t use a database for items that are mostly static, hardly ever change are in the hundreds. E.g. 50 states in the US. 🇺🇸 If you don't want incremental ints, then consider and in this order. 1. ULIDs 2. CUIDs 3. Hash Ids And yes, there is UUID v7, but still I would consider lower than the ones above.

134

137 Comments

When you join a new org or switch teams in the same, it is quite an unsettling and borderline anxious experience. Here are a few things that I did to ramp up faster. 1. I consciously made an effort to remain unblocked 2. I read a ton of code and its history, sometimes even unrelated 3. I asked questions about the past, the present, and the future 4. I took up relatively mundane tasks - cross-team work, tests, and docs 5. I extended a helping hand in whatever capacity I could 6. I proactively met skip-level leaders and managers to understand the vision Some companies do have a culture of pairing up with someone existing in the team, but even if you do not get a mentor, it is important that you still navigate the situation and ramp up as quickly as you can. The above list is not exhaustive, by any means, and hence you can always add things that you find helpful in your context. but the lowest common denominator is to show extreme intent and interest to get output and drive outcomes. Hope this helps.

995

25 Comments

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

🚀 LazyConstants in Java JEP 526 brings constants which can be lazily initialized aka Lazy Constants. The concept was in first preview as Stable Values in JDK 25, it has been renamed to Lazy Constants and is in second preview. Lazy constants are treated as true constants by the JVM, which gives us the same immutability benefits as final fields, along with deferred initialization. ✅ Designed for objects which hold immutable data ✅ JVM treats stable values as constants, and you can get similar performance gains as final fields. ✅ Although similar to final fields, they are more flexible when it comes to the timing of initialization. ❓ How do they differ from final fields? ✔️ final fields are primarily used for managing immutability. However, final fields must be set eagerly, either during object construction for instance fields, or class initialization for static fields. ✔️ Even in cases where they are not used, all the final fields will get initialized eagerly. ✔️ Lazy Constants brings “deferred immutability” to us. ❓ How to create Lazy Constants? ✔️ A lazy constant is created using the factory method LazyConstant.of(Supplier) ✔️ When created, the lazy constant is not initialized, which means the constant is not yet set.  ✔️The first time get() is called, the supplier function is executed and the constant value is set. ❓What if multiple threads try to initialize a lazy constant at the same time? ✔️A lazy constant is guaranteed to be initialized atomically and at most once.  ✔️Only one updating thread can run the supplier function, and the other threads are blocked until the constant is initialized. #JavaByte #JavaTip #Java #JDK26 PS: This post is 100% human generated :)

5

Keeping candidates on hold without closure is unfair. If someone invests time in your process, they deserve at least a clear yes or no. Basic communication is not optional — it’s professional courtesy.

20

1 Comment

𝗧𝗵𝗲 𝗖𝗮𝗿𝗲 𝗮𝗻𝗱 𝗙𝗲𝗲𝗱𝗶𝗻𝗴 𝗼𝗳 𝘆𝗼𝘂𝗿 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗮𝗹 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿. At Amazon, engineers tend to progress from SDE-I → SDE-II → SDE-III (Senior SDE) → Principal Engineer. This somewhat sends the signal that a PE is an “SDE-IV” - which is incorrect. An Amazon, PE is a unique role with a step change in autonomy, impact and scope, and mixes tech, business and people skills. It is not exactly the same as Google L7, Meta E7, Microsoft L67, etc. It is peculiarly amazonian - and that’s why I love being an Amazon PE. When I was promoted to PE in 2014, I learned this because: (1) I had a couple of great managers (hi Dan Sommerfield and Joseph Fitzgerald!) that had experience promoting, managing and growing other PEs at Amazon. (2) Amazon had a vibrant, single PE community (https://lnkd.in/gH_pWDry), which gave me countless opportunities to be involved in the weekly PE lunches, PE Design Reviews, PE Offsites at Suncadia, etc. Being a part of this community, watching how other PEs thought and acted, was essential in calibrating and improving myself. I remember the first few events that I attended, quietly listening and thinking “wow when I grow up I want to be like X.” Back then there were about 250 PEs in the entire company. Today there’s 10x that. So scaling that PE community has been a challenge. This means newly promoted or hired PEs don’t have the same [2] that I had. They may be isolated in a team or an org without exposure to dozens or hundreds of their peers on a regular basis. We’ve also hired a lot of new managers who may not truly understand what makes an Amazon PE unique. Maybe they never managed one, or maybe they managed one in other companies where the expectations are different. This means newly promoted PEs may also not have the same [1] that I had. I worry that without [1] and [2], our PEs may end up being treated as SDE-IVs, which again: they are NOT. I have some ideas, such as ways to replicate the PE community (but more locally - perhaps by org). This is something I think about a lot. Our PEs are essential and peculiar, and I want to keep us that way. If you're a new manager of an Amazon PE: take some time to understand how your PE is not an SDE-IV. If you're a new PE: make the effort to find a community or even build your own.

365

24 Comments

SDE Series#17 - Welcome back to System Design Engineering (SDE) Series! Today, we're unveiling the 17th architectural maestro: Distributed Coordination Services – the ultimate conductors who transform chaotic distributed noise into harmonious global symphonies. The Impossible Orchestra Challenge - Imagine conducting a symphony where musicians are scattered across different continents, time zones, and concert halls. i) How do you ensure everyone starts simultaneously? ii) Who decides which violinist leads the section? iii) How do you share sheet music updates instantly? iv) How do you handle it when the lead pianist's internet connection drops mid-performance? This is exactly the challenge facing distributed systems – and Distributed Coordination Services like ZooKeeper, etcd, and Consul are the master conductors who solve this impossibly complex orchestration. The Leader Election Drama - One of the most critical coordination challenges: leader election. When multiple database replicas exist, who becomes the primary? When microservices need a coordinator, who takes charge? Coordination services run sophisticated consensus algorithms (like Raft or Paxos) to democratically elect leaders, ensure only one leader exists at a time, and automatically promote new leaders when the current one fails. It's like having an automated succession protocol that ensures the orchestra always has exactly one conductor. The Configuration Command Center - These services act as the central configuration management hub for entire distributed ecosystems. When you need to update database connection strings across 1,000 microservices, or modify load balancing rules globally, coordination services ensure consistent, atomic updates across all components simultaneously. The Distributed Lock Genius - Ever tried coordinating bathroom usage in a house with one bathroom and ten people? Distributed locks solve the digital equivalent. When multiple services need exclusive access to a shared resource, coordination services provide distributed mutexes – ensuring only one service can access critical sections at a time. Real-World Maestros - When Kafka coordinates message partitions across brokers, when Kubernetes manages pod scheduling across clusters, when Netflix coordinates service deployments globally – that's distributed coordination services conducting the complex symphony of modern infrastructure. The Consensus Revolution - Distributed Coordination Services represent the solution to one of computer science's hardest problems: achieving consensus in distributed systems where networks partition, nodes fail, and timing is unreliable. They're the invisible maestros ensuring our chaotic, distributed digital world performs like a perfectly synchronized global symphony. Next up: Full-Text Search - 18th and Final SDE Series Edition! Global Platform Engineers Network #SystemDesign #DistributedSystems #ZooKeeper #Coordination #Consensus #ServiceDiscovery #Technology #Engineering

4

Built my first MCP server. It finds offline businesses using Serper and sends the data to Clay via a webhook. After 6 months of deliberation. And multiple discussions with Anirudh and Romit, where I asked them 10000 questions, I finally built it. Why now? Because I feel it has become important enough that businesses can’t afford to ignore it anymore. Especially automation agencies like us. Rapid adoption from all three big LLM providers Anthropic, OpenAI and Google. Plus platforms like Zapier, Postman, Pipedream have made it possible to (i) easily create servers and/or (ii) integrate it into your workflows for a growing number of use cases everyday. What does my MCP server do? 1) It automatically creates the right queries to search on google using Serper. Selects the cities I want to target based on the states I mention. 2) Allows for batch creation and modularity for the number of pages I want to search. If I am looking for hotels I'll search for 20 pages vs searching for physical therapists where 5 pages should suffice. 3) Stores the API responses into a local folder as a csv file. Each run has a dedicated folder so I can always go back and access the data if I want. 4) Extracts the business details from the JSON responses and creates the final csv I can import to Clay. 5) Then it gets interesting because it also asks me if I'd like to directly send this data to a webhook table in Clay. This means even the manual import step is not necessary. For now at-least it seems like there are a few gaps: 1) Context window is a challenge, with Claude’s desktop client at-least. 2) Tool selection is not perfect. Both these things will drastically improve in the coming months. My assumption also is that using a client like Cursor will make things better, need to test. The big takeaway I had was the benefits of building your own server. I thought earlier, if out of the box MCP servers will become more readily available then users won’t need to spend as much time building, configuring or implementing their own servers. However, it turns out building your own server gives you the advantage of capturing your business logic more reliably. For example even if there are out of the box servers available for Serper (tongue twister much), I wouldn’t be able to achieve some parts of my workflow with it. Like my querying, batching logic, or the ability to transfer data via webhook to Clay. I could have potentially integrated other MCPs or tools to achieve the same but as I mentioned tool selection is currently a problem. There may be even better approaches to solve for a multi step workflow which captures your business context and needs - than just directly building that into your MCP server. Need to explore and build more.

75

20 Comments

A candidate appearing for SDE-II interviews at Amazon was asked the LFU Cache hard LC problem during his coding interview. Another candidate appearing for Senior SWE at Uber was given this problem to solve during his coding interview. 1 failed the interview. 1 landed the offer. The difference? Pattern-based thinking. Let me break it down for this exact question and how it works when you are under pressure, stressed, and the interviewer is watching. Btw, this is the exact skill that I teach with my DSA-pattern Ecosystem, you can check it out here: https://lnkd.in/gqXTkSev 5100+ students are already using it, it has 50+ videos covering each pattern in detail and how to spot it, 250+ handpicked problems mapped to patterns, and you get AI-assisted feedback. [1] Step 1: Decode what the problem is -really- asking - You see: get, put, eviction, and the words "must run in O(1) average time". - That should ring a bell: this is a cache design problem. - Pattern in your head:   - O(1) lookup → HashMap for key to node.   - O(1) eviction according to some policy → Linked list or ordered buckets. If your first thought is "I will scan all entries and find the minimum frequency", you have already lost. That is O(n). [2] Step 2: Name the eviction policy pattern - Here the policy is:   - Remove Least Frequently Used.   - If tie, remove Least Recently Used among those.  - That means we need to track two things at once: frequency and recency. - Pattern:   - HashMap: key → node (value, freq, pointers).   - Another map: freq → doubly linked list of nodes with that frequency, ordered by recency.   - A variable minFreq to know which list to evict from. Once you say this out loud, the interviewer already knows you are on the right track. [3] Step 3: Walk through operations in your head - get(key)   - If key not found, return -1.   - If found:     - Take node out of list freq = f.     - Increase its freq to f + 1.     - Move it to the head of list f + 1.     - If old list becomes empty and f was minFreq, bump minFreq. - put(key, value)   - If capacity is 0, do nothing.   - If key already exists: update value, then treat as get(key) to increase freq.   - Else new key:   - If cache is full:       - Go to list with minFreq.       - Evict the node at the -tail- of that list (LRU among LFU).       - Remove from both maps.     - Insert new node with freq 1 at head of list 1.     - Set minFreq = 1. Notice how every step is O(1) because you never loop over all keys. [4] Step 4: How this looks in an interview under pressure A candidate who fails usually: - Jumps straight to code. - Uses a single map plus a linear scan to find LFU on every eviction. - Realises near the end it is not O(1), gets stuck, starts patching. A candidate who passes does this: - Spends 3–4 minutes talking through the pattern. - Draws: keyMap, freqMap, and a small example of minFreq changing. - Only then writes code that is almost a direct translation of the dry run.

139

9 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

"For HRA, law asks for landlord’s PAN number. Some companies ask for the PAN card copy. That’s not compliance — that’s overreach." CBDT rules are clear: PAN number only if rent > ₹1 lakh/year. Demanding copies risks privacy breaches under the DPDP Act 2023 and creates liability with zero legal benefit. Why collect more data than the law requires? #HRA #Compliance #Privacy #PAN #DPDPAct #TaxRules #employeeright All India Employee Association

1

Incomplete thoughts about compensation (7) Money doesn’t compensate for a crappy job – every engineer I’ve met and talked to about bad previous jobs all said without exception that a high compensation doesn’t compensate for a terrible job. To be clear, these are/were all good engineers – I would be happy to work with them again in the future (and I’m happy to currently work with some of these at Databricks). Beside being good, they all had massive compensation working either in financial companies (e.g. high speed trading at hedge funds) or big tech companies (e.g. Meta, even after their stock did 4x) but still they had no regret moving on to find a better job. “Better” had different meanings for them, some were looking for just a less toxic environments, some were looking for a different domain and others were looking for a better work life balance. Obviously money matters, but for engineers that make quite a lot of money (as being in the top 1% of income), more money might not be what you are looking for. Similarly to the point I made in other posts, not everyone wants the additional responsibilities/stress of becoming more senior, the people's responsibility of becoming a manager or having to work on a crappy tech stack – even if money is involved. TL;DR: Consider your compensation as one input of your job (and whether you should switch job) but don’t treat it as the main/only criteria – would it be because in the long term, growth is more important and that the weight of your compensation will decrease as you earn more. #softwareengineering #compensation #growth #happiness Illustration's prompt: cartoon of a software engineer being rich but feeling stressed and miserable

25

6 Comments

After a decade working across companies like #Microsoft and #Amazon, here are 5 questions I always ask a manager before joining their team 1. What does your team do — and how does it tie to the company’s core metrics? What does “success” look like for this team? How does your work connect to revenue, customers, or long-term strategy? In times of tighter budgets and layoffs, working on something that matters is non-negotiable. 2. What will my scope be in the first 6–12 months? What problems will I own? Who will I collaborate with to deliver them? Clarity on scope helps you assess whether this role stretches you — or boxes you in. 3. What do you expect from engineers on your team? Managers set the culture. Understanding how they think about ownership, quality, pace, and communication tells you a lot about what day-to-day life will actually look like. 4. What does the team composition look like? How many people at each level? A healthy mix matters. Too many peers can mean competition. Too few can mean overload or unrealistic expectations. 5. Where do you see my strengths adding the most value? Trust goes both ways. A good manager wants to understand what you’re great at so they can align your growth with the team’s success. #CareerGrowth #BigTech #SoftwareEngineering #EngineeringLeadership #TechCareers #JobSearch

109

5 Comments