Subhodip Banerjee

35 practical thoughts on system design Core Principles 1. Every system is a trade-off -> you never get speed, cost, and simplicity all at once. 2. Latency compounds -> every millisecond added across layers adds up to user pain. 3. Scalability ≠ performance -> one handles growth, the other handles speed. 4. Read vs. write paths -> scaling each requires completely different strategies. 5. Design for change, not perfection -> requirements will shift. Databases & Storage 6. Indexes are levers -> high-selectivity columns are worth indexing, low ones often aren’t. 7. Replication helps reads, partitioning helps writes -> don’t confuse the two. 8. Dual writes are a lie -> without coordination, you will see drift. 9. Event stores > queues (sometimes) -> better traceability, worse simplicity. 10. Cache invalidation is still the hardest problem -> freshness vs. performance is the eternal fight. Reliability & Consistency 11. Idempotency saves you -> retries without it will hurt. 12. Fail fast, fail loud -> silent failures sink systems. 13. Eventual consistency is a feature -> not a bug, but only if the business allows it. 14. Conflict resolution in active-active is business logic, not infra. 15. Durability isn’t free -> syncing across regions has cost and latency. Architecture Patterns 16. Microservices are an org structure, not a tech goal. 17. Monolith first, modular second, microservices last -> don’t jump too early. 18. Choreography scales, orchestration simplifies -> pick based on team maturity. 19. Serverless buys you focus, costs you control. 20. Queues don’t remove work, they smooth it. Observability & Operations 21. Tracing > logging -> logs tell you “what”, traces tell you “why”. 22. Metrics rot without ownership -> measure what someone actually uses. 23. Retries without backoff = DDoS on yourself. 24. Dead-letter queues aren’t optional -> every system has poison messages. 25. Levers > knobs -> design quick kill switches and controls to contain blast radius. Performance & Cost 26. Optimize the hot path, not the cold path. 27. Most bottlenecks live in the database, not the code. 28. Horizontal scaling beats vertical scaling ->until coordination kills it. 29. Warm caches mask bad queries -> measure against cold starts too. 30. The cheapest resource is disk, the most expensive is time. People & Process 31. The best architecture dies without documentation. 32. System design reviews aren’t about diagrams, they’re about trade-offs. 33. Small PRs are for speed, big PRs are for context -> balance both. 34. A senior engineer’s role in design is asking the uncomfortable “what if”. 35. No design survives first contact with production -> but good ones bend instead of break. Want to sharpen your instincts with daily practice? Check out joinenginuity.com One system design question every day, with streaks, badges, and leaderboards, and a dashboard to keep you sharp. Enjoy the rabbit hole!

1,459

93 Comments

If I were your interviewer in a System Design interview, here’s how I’d evaluate your answers — based on these 40 core fundamentals: 1. Scalability – Vertical vs horizontal; default to stateless horizontal scale 2. Latency & Throughput – Know P50/P95/P99 and tradeoffs 3. Capacity Estimation – Estimate QPS, storage, bandwidth 4. Networking Basics – TCP, HTTP/HTTPS, TLS, UDP, DNS 5. SQL vs NoSQL – Decide by access patterns, joins, consistency 6. Data Modeling – Structure to optimize hot queries 7. Indexing – Right indexes help reads, wrong ones hurt writes 8. Normalization – Normalize for writes, denormalize for reads 9. Caching – App/DB/CDN; write-through/back, TTLs 10. Cache Invalidation – TTLs, versioning, stampede protection 11. Load Balancing – L4/L7, RR, least-connections, hashing 12. CDN & Edge – Serve static content near users 13. Sharding – Hash/range/geo; handle hot keys, rebalancing 14. Replication – Sync/async, leader/follower, read replicas 15. Consistency Models – Strong, eventual, causal 16. CAP Theorem – In partition, pick A or C 17. Concurrency – Locks, MVCC, retries 18. Multithreading – Pools, contention, switching 19. Idempotency – Same request, same effect 20. Rate Limiting – Fairness and protection 21. Queues & Streams – Kafka, RabbitMQ; smooth spikes 22. Backpressure – Manage slow consumers/load shedding 23. Delivery Semantics – At-most/least/exactly-once 24. API Design – REST vs gRPC; human vs machine optimized 25. API Versioning – Additive only; never break clients 26. AuthN & AuthZ – OAuth2, JWT, RBAC/ABAC 27. Resilience – Circuit breakers, timeouts, retries 28. Observability – Logs, metrics, traces, SLI/SLO 29. Health Checks – Detect failures, auto-replace 30. Redundancy – Avoid SPOFs; use multi-AZ/region 31. Service Discovery – Dynamic endpoints, central config 32. Deployment – Canary, blue/green, rollbacks 33. Monolith vs Microservices – Split only if ops cost justified 34. Distributed Transactions – Use sagas, avoid 2PC 35. Event Sourcing/CQRS – Append-only logs, split models 36. Consensus – Raft, Paxos, quorum reads/writes 37. Data Privacy – Encryption, GDPR/CCPA 38. Disaster Recovery – Backups, RPO/RTO, test it 39. Serialization – JSON, Avro, Proto 40. Real-Time Delivery – Polling, SSE, WebSockets 📌Comment “Fundamentals” if you want access to this mindmap, I’ll send it you in the comments!!

996

146 Comments

Trust me, System Design is not HARD. If you follow this 1 Modular Monolith Architecture ↳ https://lnkd.in/edUqkCKR 2 Redis Use Cases ↳ https://lnkd.in/ekJMjMG3 3 Idempotent API ↳ https://lnkd.in/erMkqwq4 4 Saga Design Pattern ↳ https://lnkd.in/eFXC4-aJ 5 How DNS Works ↳ https://lnkd.in/e8H3EGvp 6 How Consistent Hashing Works ↳ https://lnkd.in/eUP9DbCg 7 Service Discovery ↳ https://lnkd.in/eCYYwQfU 8 How API Gateway Works ↳ https://lnkd.in/eMCr9VjE 9 What Happens When You Type a URL Into Your Browser ↳ https://lnkd.in/eusuDn5z 10 Microservices Lessons From Netflix ↳ https://lnkd.in/eZSM3CRB 11 How Websockets Work ↳ https://lnkd.in/euHDJUfH 12 Bloom Filters ↳ https://lnkd.in/e2duES7s 13 How Databases Keep Passwords Securely ↳ https://lnkd.in/edd8-N5k 14 How JWT Works ↳ https://lnkd.in/ek9_BTUc #sde1 #sde2 #sde3 #hiring #systemDesign #layoff #tcs

768

15 Comments

Eating the exception poisoning the app!, Handling the errors properly and propagates the exception/logical error to the controller or the use case, will be too helpful to write a robust logic and handles any case in a proper way. We have 2 options. 1. Use Result<T> This is too helpful class holds the data or exception, and it's part of kotlin standard library (so it's too stable), but the limitation is, it only propagates the T or exception, not other errors, and if you uses when statement you will be forced to use else. Something like .onSuccess { user -> println(user.name) } .onFailure { error -> when (error) { is NetworkException -> println("Failed to fetch user") is ParsingException -> println("Failed to parse user") else -> println("Unhandled error") } } 2. Use Either<T, E> This is the best solution (until kotlin 2.4 released!) return type will be either data T, or Error E, and this error could be a sealed class, which means it will be exhaustive when, and it's functional, which means you can flatmap and mapLeft and much more (Documentation link https://lnkd.in/dTQ_qdVd) Note: In kotlin conf 2025, there are an announcement for kotlin 2.4 for new class types called error and the union type only for Rich errors, something like error class NetworkError error class ParsingError fun getUser(): User | NetworkError | ParsingError Happy coding 😄 #kotlin #android #kmp #cmp #software_engineering

144

9 Comments

API design is an important step in any system design interview. You'll need to be able to: 1. Choose the right "API protocol" ie. REST, GraphQL, RPC 2. Follow proper protocol semantics 3. Handle follow up questions about pagination, security, versioning, etc. I'll admit, my bias is that interviewers who are nit-picky here are focused on the wrong things. BUT, that being said, it's easy enough to get right if you know the rules of the game. We recently launched a new deep dive on API Design complete with a YouTube video to match! Let me know what you think :) Article: https://lnkd.in/gih4Wyp3 Video: https://lnkd.in/gy_QNvRG

181

6 Comments

** Razorpay Frontend Interview Experience for Senior Engineer Role ** 🧩 Round 1: Technical + Project Deep Dive Discussion around past projects, component libraries, and performance optimizations. Also discussions around Micro Frontends using Module Federation and the trade-offs compared to monolithic builds. Takeaway: Don’t just explain what you built — explain why you made those decisions and what impact they had. ⚙️ Round 2: Core JavaScript A deep dive into language fundamentals — event loop, closures, inheritance, type coercion — followed by polyfill implementations like Promise.all and debounce. Discussion around memory leaks, useEffect cleanup patterns, and performance best practices. Takeaway: Know your JavaScript deeply. Writing a polyfill is often the best way to prove understanding. ⚛️ Round 3: Machine Coding (React) This was a hands-on session to build a solution from a given problem statement. Takeaway: Razorpay values precision. Even small misses in validation or async flow can make the difference. If you want to learn about more questions asked by Razorpay, try: https://lnkd.in/d2rA9teT -- Follow Mansi Gupta and Devtools Tech for more.

165

3 Comments

In AOSP (Android Open Source Project), many design patterns are used. We can learn a lot from those examples. I am sharing some of the examples. • Observer: View . OnClickListener, TextWatcher. Notifies multiple observers of changes without tight coupling. • Factory Method: LayoutInflater . from(context). Centralized object creation, hides construction details. • Builder: AlertDialog . Builder, NotificationCompat . Builder. Helps construct complex objects step by step. • Singleton: Application, ActivityManager. Ensures a single instance of system services across the app or system. • Adapter: RecyclerView . Adapter. Bridges between data sources and UI components. • Strategy: LayoutManager in RecyclerView (Linear, Grid, StaggeredGrid). Lets you switch behaviors at runtime. • Command: Handler . post(Runnable). Encapsulates a request as an object. Follow Outcome School for knowledge-packed content. Keep Learning, Keep Sharing, and Keep Growing. Software engineers like you join Outcome School to achieve the outcome that is a high-paying tech job. Join Outcome School: https://outcomeschool.com #OutcomeSchool #SoftwareEngineer #Tech #AndroidDev #Android #Kotlin 

212

6 Comments

📌 𝗥𝗲𝗹𝗶𝗮𝗯𝗹𝗲 𝘁𝗲𝘀𝘁𝗶𝗻𝗴 𝗶𝘀 𝗮𝘀 𝗲𝘀𝘀𝗲𝗻𝘁𝗶𝗮𝗹 𝗮𝘀 𝗿𝗲𝗹𝗶𝗮𝗯𝗹𝗲 𝗰𝗼𝗱𝗲. At Zepto, we kept hitting a wall with 𝘁𝗵𝗶𝗿𝗱-𝗽𝗮𝗿𝘁𝘆 𝗔𝗣𝗜 𝗽𝗿𝗼𝘃𝗶𝗱𝗲𝗿𝘀' 𝘀𝗮𝗻𝗱𝗯𝗼𝘅𝗲𝘀 that were slow, unreliable, or simply unavailable - 𝗯𝗹𝗼𝗰𝗸𝗶𝗻𝗴 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲𝘀 𝗮𝗻𝗱 𝘄𝗮𝘀𝘁𝗶𝗻𝗴 𝘃𝗮𝗹𝘂𝗮𝗯𝗹𝗲 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗵𝗼𝘂𝗿𝘀. So we built our own: 𝗨𝗻𝗶𝘃𝗲𝗿𝘀𝗮𝗹 𝗠𝗼𝗰𝗸 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 🚀 A self-hosted simulation engine for 𝗛𝗧𝗧𝗣, 𝗴𝗥𝗣𝗖, 𝗞𝗮𝗳𝗸𝗮 & 𝘄𝗲𝗯𝗵𝗼𝗼𝗸𝘀 that lets teams:  • Mock without writing code  • Proxy + mock selectively for hybrid testing  • Record & replay real responses  • Simulate event-driven workflows The outcome? 𝗥𝗲𝘀𝗶𝗹𝗶𝗲𝗻𝘁 𝘁𝗲𝘀𝘁 𝗲𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁𝘀, 𝗳𝗮𝘀𝘁𝗲𝗿 𝗤𝗔, 𝗮𝗻𝗱 𝘀𝗶𝗴𝗻𝗶𝗳𝗶𝗰𝗮𝗻𝘁 𝗯𝗮𝗻𝗱𝘄𝗶𝗱𝘁𝗵 𝘀𝗮𝘃𝗶𝗻𝗴𝘀 - while giving teams complete control over their testing ecosystem. Rich, one of our rockstar Engineering Managers, has detailed it in one of our latest Tech Blogs. The link is in the first comment. #ZeptoTechXPress

302

16 Comments

🚨 Imagine this: You’re in a 𝐬𝐲𝐬𝐭𝐞𝐦 𝐝𝐞𝐬𝐢𝐠𝐧 𝐢𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰 and the interviewer asks: “How would you design this service so it never goes down?” Most engineers stumble here, not because they don’t know distributed systems, but because they forget the 𝐠𝐨𝐥𝐝𝐞𝐧 𝐫𝐮𝐥𝐞𝐬 𝐨𝐟 𝐚𝐯𝐚𝐢𝐥𝐚𝐛𝐢𝐥𝐢𝐭𝐲. Here are 𝟏𝟎 𝐫𝐮𝐥𝐞𝐬 you can’t afford to miss 👇 ↳1. 𝐑𝐞𝐝𝐮𝐧𝐝𝐚𝐧𝐜𝐲 𝐞𝐯𝐞𝐫𝐲𝐰𝐡𝐞𝐫𝐞 – No single point of failure. Always have backups. ↳2. 𝐋𝐨𝐚𝐝 𝐛𝐚𝐥𝐚𝐧𝐜𝐢𝐧𝐠 – Distribute traffic smartly to keep systems alive under pressure. ↳3. 𝐇𝐞𝐚𝐥𝐭𝐡 𝐜𝐡𝐞𝐜𝐤𝐬 – Detect failures early before users feel them. ↳4. 𝐆𝐫𝐚𝐜𝐞𝐟𝐮𝐥 𝐝𝐞𝐠𝐫𝐚𝐝𝐚𝐭𝐢𝐨𝐧 – Even if part of the system breaks, keep core features running. ↳5. 𝐅𝐚𝐢𝐥𝐨𝐯𝐞𝐫 𝐦𝐞𝐜𝐡𝐚𝐧𝐢𝐬𝐦𝐬 – Auto-switch to healthy nodes when something dies. ↳6. 𝐃𝐚𝐭𝐚 𝐫𝐞𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧 – Multiple copies = peace of mind (but watch consistency trade-offs). ↳7. 𝐒𝐭𝐚𝐭𝐞𝐥𝐞𝐬𝐬 𝐬𝐞𝐫𝐯𝐢𝐜𝐞𝐬 – Easy scaling, easier recovery. ↳8. 𝐑𝐚𝐭𝐞 𝐥𝐢𝐦𝐢𝐭𝐢𝐧𝐠 & 𝐭𝐡𝐫𝐨𝐭𝐭𝐥𝐢𝐧𝐠 – Don’t let one bad client take down the system. ↳9. 𝐌𝐨𝐧𝐢𝐭𝐨𝐫𝐢𝐧𝐠 & 𝐚𝐥𝐞𝐫𝐭𝐢𝐧𝐠 – Availability is nothing without visibility. ↳10. 𝐂𝐡𝐚𝐨𝐬 𝐭𝐞𝐬𝐭𝐢𝐧𝐠 – Break things on purpose (Netflix’s Chaos Monkey style) to prepare for real disasters. 💡 Master these, and you’ll look like someone who’s been 𝐛𝐮𝐢𝐥𝐝𝐢𝐧𝐠 𝐬𝐲𝐬𝐭𝐞𝐦𝐬 𝐚𝐭 𝐬𝐜𝐚𝐥𝐞 𝐟𝐨𝐫 𝐲𝐞𝐚𝐫𝐬, even if you’re “just” preparing for an interview. 🔑 Remember: In interviews, 𝐚𝐯𝐚𝐢𝐥𝐚𝐛𝐢𝐥𝐢𝐭𝐲 𝐢𝐬 𝐧𝐨𝐭 𝐩𝐞𝐫𝐟𝐞𝐜𝐭𝐢𝐨𝐧 - it’s resilience. 👉 Which of these do you think candidates forget the most often? Drop it in the comments - I’d love to hear your take! Learn more about system design and software architecture: 📌 Grokking the System Design Interview - https://lnkd.in/giwyzfkT 📌 Grokking System Design Fundamentals - https://lnkd.in/gtcCT-dJ #SystemDesign #SoftwareEngineering #Interviews #HighAvailability #DesignGurus

108

Here are the 11 most actionable tips I can give you on approaching coding problems in technical interviews after having interviewed 1000+ Software Engineers across Google, Paytm, Amazon & various startups (in the last 15+ years of my journey) Step 1: Start With Clarifying Questions | |__ ➝ Don’t rush into coding. |      Ask about edge cases, constraints, and input formats: |         – Can parameters be empty? |         – Are there duplicates? |         – Are inputs always lowercase? |         – What should I return if there’s no valid answer? |      These answers shape your approach and avoid rework. | v Step 2: Manual Walkthrough With Examples | |__ ➝ Use given test cases. |      Draw out the example, underline or highlight key words, and manually reduce the problem. |      This helps you: |         – Find optimal substructures (e.g., shortest valid substring) |         – Catch mistakes before coding |      If you can “see” the answer by hand, you can code it more confidently. | v Step 3: Start Naive, Think Out Loud | |__ ➝ Always share your brute-force approach. |      Describe it step-by-step: |         – Use nested loops to anchor possible start/end indices |         – Check validity at each step |         – Keep track of the best result (length, indices) |      This shows the interviewer you understand basics before optimizing. | v Step 4: Recognize Patterns Early | |__ ➝ Ask yourself: |         – Is there a window I can slide over the input? |         – Can I avoid redundant work using two pointers? |      If yes, transition to a sliding window approach. |      Don’t stick with brute-force if a better pattern fits. | v Step 5: Build the Right Data Structures | |__ ➝ Use hash maps, not just sets. |      When frequency or duplicates matter, always track counts, not just presence. |      E.g., if a substring must contain all required words with their counts, you need a map for both “target” and “current window.” | v Step 6: Dry Run Your Optimized Approach | |__ ➝ Before you code, walk through your window logic by hand: |         – Expand right pointer to include more words |         – Shrink left pointer to minimize window once all requirements are met |         – Update best answer (start, end, length) as you go |      *Keep track of when your window is valid and when it isn’t.* | v Step 7: Implement, Then Tighten the Loop | |__ ➝ When you start coding: |         – Set up all maps and pointers first |         – Incrementally update your window |         – Always check: Did you match all targets? Can you shrink further? |      Use variables like minLength, bestStart, bestEnd to track answers. | v Step 8: Check Edge Cases (Empty/No Solution) | |__ ➝ Always handle what to return if there’s no valid solution. |      Don’t forget: If your bestStart/bestEnd were never updated, return an empty string (or -1, depending on the problem). | v Continued in Comments ↓

309

38 Comments