Bitumoni Thakuria’s Post

A single slow Database query almost brought down a production system I worked on. Not because of the query itself, but because it consumed every available thread, leaving nothing for the services that actually mattered. The fix? Bulkhead Semaphore pattern. Isolate your thread pools. Set a queue. Define a fallback. The slides show exactly how. Full Resilience4j docs: https://lnkd.in/dyMxUx_j #java #springboot #backend #resilience4j #softwareengineering

How I improved API performance by ~40% 🚀 Problem: Slow response time due to heavy DB queries What I changed: • Optimized SQL queries • Added indexing • Reduced unnecessary joins • Used proper pagination Result: Faster APIs Better user experience Most performance issues are not in code, they’re in the database. #Backend #Java #Performance #Microservices #TechTips

🚨 “Let’s add cache” is not always the right solution Caching improved one of my APIs from 800ms → 50ms. But later… it caused stale data issues in production. 💥 Problem: Users were seeing outdated data after updates Root cause: Cache was not invalidated properly ✅ Fix: - Added cache eviction on updates - Used TTL for safety 💡 Takeaway: Caching is easy to add. Hard to maintain correctly. Always plan invalidation before implementation. #Java #SpringBoot #BackendDevelopment #SoftwareEngineering  #Microservices #JPA #RESTAPI  #DeveloperLife #CareerGrowth

One pattern that consistently improves performance in backend systems is introducing a caching layer between services and the database. In early stages of development, applications often query the database directly for most requests. It works fine when traffic is low. But as systems grow, repeated queries for the same data start putting unnecessary pressure on the database. In one system I worked on, introducing a caching layer for frequently accessed data significantly reduced database load and improved response times for several APIs. Caching isn’t always the first thing teams think about when designing services, but it often becomes one of the simplest ways to improve performance at scale. Like many things in distributed systems, small architectural adjustments can have a big impact once traffic increases. #BackendDevelopment #Java #Microservices #SoftwareEngineering

Spring Boot @RequestScope vs Singleton — Hidden concurrency issue ⚠️ By default: 👉 Beans are Singleton (shared across threads) But what if you store request-specific data? 🤔 ❌ Problem: Multiple users → same instance → data leakage Solution 👇 @RequestScope public class RequestData { ... } 💡 What happens: ✔ New bean per request ✔ Thread-safe data handling ⚠️ Mistake: Storing user data in Singleton beans ❌ 👉 Leads to unpredictable bugs in production Design for concurrency, not just functionality 🔥 #SpringBoot #Java #Concurrency

I fixed a 4-second Spring Boot API without scaling anything. ⚠️the real problem? 47 database queries per request. 🧩we thought it was a performance issue. so we tried: • more RAM • indexes • monitoring CPU nothing changed. 🔍then I checked the SQL logs. and saw the real issue: → N+1 query problem → JPA lazy loading → 47 queries for a single API call 🛠️ the fix was simple: replace multiple queries with one optimized query: JOIN FETCH everything in a single DB call. 📉 result: • 4000ms → 190ms • 47 queries → 1 • DB CPU dropped massively 📌 lesson: don’t scale first. first understand what your code is doing to the database. #SpringBoot #Java #Backend #SystemDesign #APIs #SoftwareEngineering

Java 21 Virtual Threads will not make your API faster. In fact, they might take your entire system down. Right now, everyone is rushing to upgrade to Spring Boot 3.2 to flip this magical switch: spring.threads.virtual.enabled=true The promise is intoxicating: Tomcat is no longer limited to 200 heavy OS threads. You can now effortlessly handle 10,000+ concurrent requests. You deploy it. You expect blazing-fast performance. Instead, your app freezes, throws endless SQLTransientConnectionExceptions, and completely dies. 💥 What went wrong? You just DDoS'd your own database. Virtual Threads scale your compute layer infinitely. But they do absolutely nothing to scale your infrastructure. Let’s look at the math: If your API gets a sudden spike of 5,000 requests, Virtual Threads will instantly accept all 5,000. But your HikariCP database connection pool only has 10 connections by default. You now have 5,000 lightweight threads violently racing to acquire one of 10 heavy database connections. 9,990 threads are blocked. The Hikari pool reaches its timeout. The application cascades into a catastrophic failure. The Senior Architect Reality Check: Virtual threads do not execute code faster. They just allow you to wait more efficiently. • If your bottleneck was waiting for 3rd-party APIs, Virtual Threads are pure magic. • If your bottleneck was your Database, Virtual Threads will just crash it faster. How to survive the upgrade to Java 21: 1. Implement Bulkheads: Use Semaphores to limit exactly how many Virtual Threads are allowed to query the database at the same time. Protect your downstream! 2. Watch for "Pinning": If you have legacy code using synchronized blocks or native JNI calls, it will "pin" the OS thread, completely breaking the Virtual Thread magic. Upgrade to ReentrantLock. 3. Never pool them: Virtual threads are incredibly cheap. Never put them in a ThreadPoolExecutor. Create them, use them, throw them away. Have you made the jump to Java 21 yet? Did you hit the database bottleneck? 👇 #Java21 #VirtualThreads #SpringBoot #SystemDesign #Microservices #BackendArchitecture #SoftwareEngineering #PerformanceTuning #LogicLedaMagic

I had an API returning correct data. But response time was too high. Issue turned out to be unnecessary data being fetched from DB. Reduced fields, optimized query. Small change, big impact. #Backend #Java #SpringBoot #Performance

4 releases in a weekend: Testcontainers Java module, AWS CLI bundled, Step Functions intrinsics, RDS Data stubs. Free, open-source, MIT licensed. TL;DR We shipped 4 releases this weekend (v1.2.6 through v1.2.9): org.ministack:testcontainers-ministack:0.1.0 on Maven Central 62 bug fixes found by running 2,490 tests across all 41 services AWS CLI bundled in the Docker image — init scripts just work Step Functions intrinsics — 7 new functions (ArrayContains, MathAdd, UUID, etc.) RDS Data API stubs — test database provisioning without Docker-in-Docker https://ministack.org https://lnkd.in/e-RBG-yn

While working on backend systems, we’ve traditionally used ExecutorService to handle concurrent transactions — especially for processing shipping data and storing it in the database. It works well… but managing threads at scale always needs careful tuning. Recently, I started evaluating virtual threads (Java 21) as an alternative. On paper, they look great: ✔️ Lightweight threads ✔️ Better scalability for concurrent tasks ✔️ Simpler code compared to complex thread pools But while exploring this, a few practical concerns came up: ❌ Not all operations benefit → CPU-heavy tasks don’t gain much ❌ Blocking calls still matter → If you block on I/O without proper handling, gains reduce ❌ Debugging & monitoring → Traditional tools may not give clear visibility ❌ Library compatibility → Some older libraries may not be optimized for virtual threads 🧠 What I realized: Virtual threads are powerful… but they need to be used in the right kind of workload. 💡 My takeaway: They are great for I/O-heavy, high-concurrency systems — but not a direct replacement for everything. Still exploring this space, especially how it fits into real production systems. Would love to hear if anyone has tried virtual threads in real-world use cases. #Java #Java21 #VirtualThreads #Backend #Concurrency #SystemDesign #SoftwareEngineering