Pratham Saroch’s Post

Real Microservices Lesson: When One Service Goes Down, Everything Can Crash While working with microservices, I encountered an issue that many systems face but often only realize after it breaks things. Let’s say there are two microservices: MS1 and MS2. MS1 depends on MS2 for fetching some data. Everything works fine… until MS2 goes down. Now here’s where things get interesting 👇 Even after MS2 was stopped, MS1 kept sending requests to it. Those requests kept waiting for a response that would never come. 💥 Problem: The application’s thread pool started getting exhausted because threads were stuck waiting on a non-responsive service. 📉 Impact: Eventually, the entire application crashed with multiple 500 Internal Server Errors. 🛠️ Solution: Circuit Breaker To fix this, I implemented a Circuit Breaker pattern. Think of it as a safety switch for microservices: -> When a dependent service fails repeatedly, the circuit breaker trips (opens) -> It stops further calls to that failing service. ->Instead of waiting, the system returns a fallback response. ->This gives the downstream service time to recover and avoiding system to crash. ⚡ Why it matters: Prevents cascading failures Avoids thread exhaustion Enables graceful degradation Improves overall system resilience 💡 Key takeaway: In distributed systems, failure is inevitable. What matters is how gracefully your system handles it. 👉 In the next post, I’ll explain the states of a circuit breaker and share a code example where I’ve applied it. #Microservices #Java #SpringBoot #SystemDesign #BackendDevelopment #Resilience #CircuitBreaker

🚀 Backend Learning | Horizontal vs Vertical Scaling While working on backend systems, I recently explored how applications scale to handle increasing traffic. 🔹 The Problem: • Growing user traffic leading to system overload • Increased latency and downtime • Need to scale applications efficiently 🔹 What I Learned: • Vertical Scaling: Increasing resources (CPU, RAM) of a single server • Horizontal Scaling: Adding more servers to distribute load 🔹 Key Insights: • Vertical scaling is simple but has limits • Horizontal scaling improves fault tolerance and scalability • Load balancing is essential for horizontal scaling 🔹 Outcome: • Better system scalability • Improved availability and performance • Efficient handling of high traffic Scaling systems is not just about adding power — it’s about designing for growth. 🚀 #Java #SpringBoot #SystemDesign #BackendDevelopment #Scalability #Microservices #LearningInPublic

🚀 Learning Update: Why Single-Threaded Server is Not Enough? After building a Single-Threaded Client-Server application, I explored its real limitations — and this changed how I think about backend systems. --- ⚠️ Drawbacks of Single-Threaded Server: ❌ Handles only one client at a time → If one client is connected, others must wait ❌ Blocking nature → "accept()" and I/O operations block the entire server ❌ Poor scalability → Cannot handle real-world traffic (multiple users) ❌ Slow response under load → Requests get queued → delay increases --- 💡 Solution: Multi-Threaded Server Instead of one thread handling everything, we use multiple threads. 🔁 How it works: - Each client request is handled by a separate thread - Server can process multiple clients simultaneously --- 🔥 Benefits of Multi-Threading: ✅ Handles multiple clients at the same time ✅ Better performance and responsiveness ✅ Efficient CPU utilization ✅ Foundation of real-world backend systems --- 🧠 Real Understanding: Single-threaded server = 🚶♂️ One person handling all work Multi-threaded server = 👥 Team handling multiple tasks together --- 🚀 Next Step in My Journey: I’ll implement a Multi-Threaded Server using Thread & ThreadPool to handle concurrent client requests efficiently. --- #Java #Multithreading #BackendDevelopment #SystemDesign #LearningInPublic #JavaDeveloper #100DaysOfCode

𝗧𝗼𝗱𝗮𝘆’𝘀 𝗔𝗪𝗦 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴: Database Connection Pool Exhaustion 𝗪𝗵𝗮𝘁 𝗶𝘁’𝘀 𝗮𝗯𝗼𝘂𝘁: Application starts slowing down →Eventually requests fail with DB errors 𝗦𝗰𝗲𝗻𝗮𝗿𝗶𝗼: Traffic increases → APIs become slow → Then errors like: “Connection timeout” / “Unable to get connection” 𝗙𝗶𝗿𝘀𝘁 𝗔𝘀𝘀𝘂𝗺𝗽𝘁𝗶𝗼𝗻: Database is down Network issue Server overloaded 𝗔𝗰𝘁𝘂𝗮𝗹 𝗜𝘀𝘀𝘂𝗲: All DB connections are in use No free connection available in pool 𝗪𝗵𝗮𝘁 𝗺𝗮𝗸𝗲𝘀 𝗶𝘁 𝘁𝗿𝗶𝗰𝗸𝘆: DB is running fine CPU & memory look normal Issue appears only under load 𝗪𝗵𝗮𝘁 𝗛𝗲𝗹𝗽𝘀: ✓ Increase connection pool size (carefully) ✓ Close connections properly (very common mistake) ✓ Optimize slow DB queries ✓ Monitor connection usage 𝗞𝗲𝘆 𝗟𝗲𝘀𝘀𝗼𝗻: Database problems aren’t always about DB failure… Sometimes, it’s just no connections left to use One Line Takeaway: If DB errors appear under load, check your connection pool before blaming DB. #AWS #RDS #BackendDevelopment #Java #SpringBoot #DevOps #Troubleshooting #LearningInPublic

🚫 Scaling horizontally doesn’t fix bad design. Throwing more instances at a system feels like the easiest solution… but it often just amplifies the real problem. I’ve seen systems scale from 2 → 20 instances and still struggle with: 🔹 Slow database queries 🔹 Chatty service-to-service calls 🔹 Shared state causing contention 🔹 Inefficient algorithms 🔹 Poor caching strategy Result? 📈 Higher infra cost 📉 Same performance issues 🔥 More complexity to debug 💡 What actually helps: ✔ Optimize database queries first ✔ Reduce unnecessary network calls ✔ Design stateless services ✔ Introduce caching where it matters ✔ Fix bottlenecks before scaling 👉 Scaling works best when the system is already efficient. 👉 Otherwise, you’re just scaling inefficiency. More servers ≠ better system. Better design = scalable system. #SystemDesign #Scalability #Microservices #Java #BackendDevelopment #PerformanceTuning

🧠 4. “Value Bomb Thread” (Save-worthy Content) If you're building scalable backend systems, read this 👇 Here are 5 lessons from my 10+ years as a Technical Lead: Don’t start with microservices Start with a modular monolith Database design matters more than API design Bad DB = slow system forever Caching is a superpower Use Redis early Logging > Debugging Invest in proper logs Performance is decided at architecture level Not after deployment Most developers learn these too late. Which one do you agree with the most?

Topic: Health Checks in Systems If you don’t know your system is unhealthy, you’re already late. In production systems, failures rarely happen instantly. They build up over time: • Increased latency • Memory usage spikes • Slow database responses • Dependency failures Health checks help detect issues early. Common types: • Liveness checks → Is the service running? • Readiness checks → Is it ready to handle traffic? Benefits: • Faster failure detection • Better auto-recovery (Kubernetes, load balancers) • Reduced downtime A system that reports its health clearly is easier to manage. Because visibility leads to faster action. How do you implement health checks in your services? #Microservices #DevOps #SystemDesign #Java #BackendDevelopment

Have you ever spent hours debugging something that looks fine on the surface but refuses to work no matter what you try? That was me with a Nexus Repository setup on EC2 — everything was “successful”… until it wasn’t. I ran into a situation where Nexus would start and immediately shut down, Java errors kept pointing in different directions, and logs were either missing or misleading. For a while, it looked like: a Java issue a memory issue even a permissions problem But none of that was the real problem. What was actually going on? The Nexus tarball was being extracted into /tmp, which in this environment is a RAM-backed filesystem with limited space. The archive was ~400MB, and during extraction it silently got cut off halfway. So what I ended up with was: a partially installed, corrupted Nexus setup That’s why: Java failed instantly services kept stopping logs never properly generated everything felt “randomly broken” The fix Once I spotted the real issue, the solution was simple: Moved extraction from /tmp to /opt (actual disk storage) Cleaned up corrupted files and stale PID data Reinstalled Nexus properly Boom 💥 — everything came up clean on first run. Lesson learned In DevOps, not every complex-looking failure is actually complex. Sometimes the real issue is just: “Wrong place. Wrong assumption. Wrong storage.” Always validate: where your files are extracted available disk space (df -h) integrity of downloaded archives Small oversights can look like big system failures. If you’ve ever chased a “ghost bug” that turned out to be something simple in disguise, you know the feeling. #DevOps #Linux #AWS #Jenkins #Nexus #CloudComputing #SystemAdministration #CI_CD #Troubleshooting #DevOpsEngineer #LearningInPublic

Your API is not slow because you need more servers. It’s slow because your architecture is leaking performance. Here are 5 practical ways to improve API performance in production 1️⃣ Pagination Returning thousands of records in one request is a performance trap. Split large datasets into pages to reduce response time and memory usage. 👉 Example: GET /users?page=1&size=20 2️⃣ Async Logging If every request writes logs directly to disk, your app can slow down without you noticing. Use buffered / async logging to reduce blocking and improve throughput. 3️⃣ Caching Not every request should hit the database. Store frequently accessed data in a cache layer like Redis to reduce DB load and speed up responses. 4️⃣ Payload Compression Large JSON responses increase network latency. Enable GZIP / Brotli compression to reduce payload size and improve API delivery speed. 5️⃣ Connection Pooling Opening and closing DB connections on every request is expensive. Use connection pooling for faster DB access and better stability under load. 🔥 Biggest lesson: Most API performance problems are not solved by scaling infrastructure first. They are solved by better backend design decisions. #Java #SpringBoot #JavaJobs #JavaCareers #Microservices #APIDesign #CloudArchitecture #Scalability #DistributedSystems #PerformanceEngineering #JavaProgramming #TechLeadership #LearnWithGaneshBankar

🐧𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧 𝐈𝐬𝐬𝐮𝐞 𝐚𝐭 𝟐:𝟏𝟑 𝐀𝐌… 𝐅𝐢𝐱𝐞𝐝 𝐰𝐢𝐭𝐡 𝟏 𝐁𝐚𝐬𝐡 𝐒𝐜𝐫𝐢𝐩𝐭 2:13 AM - PagerDuty alert. CPU spiking. Disk almost full. APIs timing out. Not the kind of notification you want in the middle of the night. 🔹I logged into the Server and saw this 👇 - Disk usage: 95% - /var/log was flooded with logs - One service was generating GBs of logs every hour Classic issue. But production was already impacted. 🔹Quick options: - Restart service? (temporary fix ❌) - Scale infra? (slow + costly ❌) - Fix root cause? (takes time ❌) 👉 Needed an immediate workaround 🔹I wrote a quick Bash script: #!/𝑏𝑖𝑛/𝑏𝑎𝑠ℎ 𝐿𝑂𝐺_𝐷𝐼𝑅="/𝑣𝑎𝑟/𝑙𝑜𝑔/𝑚𝑦𝑎𝑝𝑝" 𝑀𝐴𝑋_𝑆𝐼𝑍𝐸=100𝑀 𝑓𝑖𝑛𝑑 $𝐿𝑂𝐺_𝐷𝐼𝑅 -𝑡𝑦𝑝𝑒 𝑓 -𝑛𝑎𝑚𝑒 "*.𝑙𝑜𝑔" -𝑠𝑖𝑧𝑒 +$𝑀𝐴𝑋_𝑆𝐼𝑍𝐸 | 𝑤ℎ𝑖𝑙𝑒 𝑟𝑒𝑎𝑑 𝑓𝑖𝑙𝑒; 𝑑𝑜  𝑒𝑐ℎ𝑜 "𝑇𝑟𝑢𝑛𝑐𝑎𝑡𝑖𝑛𝑔 $𝑓𝑖𝑙𝑒"  𝑡𝑟𝑢𝑛𝑐𝑎𝑡𝑒 -𝑠 0 $𝑓𝑖𝑙𝑒 𝑑𝑜𝑛𝑒 🔹Ran it.. and within seconds: - Disk usage dropped from 95% → 40% ✔ - API latency normalized ✔ - Alerts stopped ✔ Production stabilized. 🔹Next steps (after fire-fighting): - Fixed log rotation properly - Added monitoring alerts 🔹Lesson learned: In DevOps, tools matter… But problem-solving under pressure matters more 🔹Sometimes: 👉 A simple Bash script > complex architecture discussion Set up limits to prevent recurrence #DevOps #ProductionIssue #Bash #SRE #OnCall #Cloud #IncidentManagement #Linux #AWS