Real Data Reveals Hidden Performance Issues in Code

🚨 I stopped loading all data at once today… and my API got smarter. Day 24 of my Backend Journey — and this is where things started feeling real-world 👇 🧠 LeetCode Learning Solved LeetCode 2515. Shortest Distance to Target String in a Circular Array 💡 What clicked: → Circular traversal thinking → Checking both directions (forward & backward) → No extra space needed ⚡ Smart iteration > complicated logic 🔗 My Submission:https://lnkd.in/gja7CGPS ☕ Spring Boot Realization Today I learned Pagination using Spring Data JPA 👉 Page = chunk of data 👉 Pageable = pagination config 👉 PageRequest = implementation Instead of loading everything: ✔ Fetch only what’s needed ✔ Add sorting + pagination ✔ Build scalable APIs 🧠 The Shift 👉 Backend is not just about working code 👉 It’s about efficient data handling Small changes like pagination = big impact in real apps 📘 Spring Boot Notes: https://lnkd.in/gRgxP7Th 📈 Day 24 Progress: ✅ Better API design understanding ✅ Improved problem-solving approach ✅ Thinking like a backend engineer 💬 Do you prefer writing optimized code first, or refining later? 👇 Let’s discuss #100DaysOfCode #BackendDevelopment #SpringBoot #Java #LeetCode #CodingJourney

🚀 Excited to share that JsonApi4j 1.4.0 is now live!  👉 https://lnkd.in/esH-K9AR This release adds support for JSON:API Compound Documents (https://lnkd.in/efzDhj5W) as a pluggable module. JSON:API's Compound Documents let you fetch a resource(s) and all related data in one request, eliminating extra round-trips and keeping everything perfectly consistent. It's a powerful way to deliver rich, interconnected data graphs efficiently - like getting an entire object tree in a single, clean response. Just add the plugin dependency, and your API can handle requests like: "/users/123?include=relatives.relatives&include=placeOfBirth"  → Fetch a user → Their relatives (users). And relatives of those relatives (users) → And the user’s place of birth (countries) All in one request. You can fine-tune how relationships are resolved and fetched via configuration, with built-in and configurable guardrails. --- JsonApi4j is an open-source framework for building APIs aligned with the JSON:API specification, with a strong focus on developer productivity and clean architecture. If you're looking for a structured and flexible way to expose JSON:API endpoints — give it a try. Feedback and contributions are always welcome! 🙌 #java #jsonapi #opensource #api

Solved a LeetCode hard in O(n). Couldn't use it in production. Last week I optimized an API endpoint that was timing out under load. The problem: filtering 50,000 order records to find duplicates based on multiple fields (customer_id, amount, timestamp within 5 min window). My first instinct? HashMap for O(n) lookup. Classic LeetCode muscle memory. Wrote it, tested locally flew through 100K records in 200ms. Pushed to staging. Staging worked. Production didn't. Here's what LeetCode doesn't teach you: garbage collection pauses are real. That HashMap was getting rebuilt on every request. With 50 requests/second, the young generation GC was running constantly. P99 latency spiked to 3 seconds because of GC pauses, even though P50 stayed at 200ms. Sure, I could've increased heap size. But that just delays full GC, making it worse when it finally hits. The fix: moved duplicate detection to PostgreSQL using a composite index and window function. Slightly slower average (350ms), but consistent. No GC spikes, predictable P99. LeetCode optimizes for algorithmic efficiency. Production optimizes for predictable latency under sustained load. What's an optimization that looked perfect on paper but failed under real traffic? #Java #Database #SystemDesign #LeetCode

🚀 Stop exposing your Entity directly in APIs. It works… but it’s a bad practice. Let’s understand why 👇 --- 👉 What most beginners do: @GetMapping("/users") public List<User> getUsers() { return userRepository.findAll(); // ❌ returning Entity directly } --- ❌ Problems: - Exposes internal DB structure - Sends unwanted fields (password, internal IDs) - Tight coupling between DB & API --- ✅ Better approach → Use DTO (Data Transfer Object) @GetMapping("/users") public List<UserDTO> getUsers() { return userService.getUsers(); // ✅ returns DTO } --- 💡 What is DTO? A simple object used to transfer only required data. Example: public class UserDTO { private String name; private String email; } --- 🔥 Why DTO is important: ✔ Hides sensitive data ✔ Controls API response ✔ Decouples DB from API ✔ Makes system scalable --- ⚡ Real-world example: Entity: User { id, name, email, password } DTO: UserDTO { name, email } 👉 Password is never exposed 🚀 --- ❌ Common mistake: Using Entity everywhere → works initially But becomes risky in production --- 📌 Key Takeaway: Entity = Database structure DTO = API contract Never mix them. --- Follow for more real backend learnings 🚀 #SpringBoot #Java #BackendDevelopment #CleanCode #SoftwareEngineer

Day 28. I fixed the N+1 problem. Or at least… I thought I did. I had this: @Entity public class User {   @OneToMany(mappedBy = "user", fetch = FetchType.LAZY)   private List<Order> orders; } And I was careful. I wasn't using EAGER. I avoided obvious mistakes. Still… something felt off. The API was slow. Query count was high. That's when I checked the logs. And saw this: → 1 query to fetch users → N queries to fetch orders Again. Even after "fixing" it. Here's what was actually happening. I was mapping entities to DTOs like this: users.stream()   .map(user -> new UserDTO(     user.getId(),     user.getName(),     user.getOrders().size()  // 👈 triggers lazy load per user   ))   .toList(); Looks harmless. But user.getOrders() → triggers lazy loading → inside a loop → causing N+1 again That's when it clicked. N+1 isn't just about fetch type. It's about when and where you access relationships. So I changed it. (see implementation below 👇) What I learned: → LAZY doesn't mean safe → DTO mapping can silently trigger queries → N+1 often hides in transformation layers The hard truth: → You think you fixed it → But it comes back in a different place Writing queries is easy. Controlling when data is accessed is what makes your backend scalable. Have you ever fixed N+1… and then seen it come back somewhere else? 👇 Drop your experience #SpringBoot #Java #Hibernate #BackendDevelopment #Performance #JavaDeveloper

One fine morning, a customer reported: “File upload sometimes fails…” Not always. Not consistently. Just sometimes. 😄 And of course, those are the best bugs. 👉 System handles 1000+ uploads daily 👉 Issue happens randomly (10–20 times) 👉 Chunk upload + merge logic (unchanged for years) 👉 Stateless architecture (or so I thought…) I jumped into debugging mode. After hours of checking: NFS configs ✅ Multi-server behavior ✅ Retry logic ✅ Logs (100 times) ✅ Observation: Chunks uploaded from Server A were not visible on Server B immediately (10–15 sec delay). Confusion level: 🔥🔥🔥 Then I did something simple (and often ignored)… 👉 Compared old vs new code Guess what changed? Just one line removed (thanks to Sonar cleanup 😅): HttpSession session = request.getSession(); And that innocent line was silently adding JSESSIONID, making requests sticky and hiding the real problem all along. 💡 So for years, reality was something like this: Stateless system... except when upload API enters the chat 😄 Or simply: stateless most of the time, secretly stateful during uploads 🎭 And the moment I removed an “unused variable”… 💥 Load balancing started behaving correctly 💥 NFS delays became visible 💥 Hidden dependency got exposed 💥 Bug said: Hello 👋 I was always here And the best realization: 👉 My application is perfectly stateless… 👉 Until the user hits the upload API and boom, it becomes emotional (stateful) 🤣🤣🤣 Lesson learned: Sometimes the bug is not in new code… It’s in removing the wrong old code 😄 And sometimes… Your system isn’t broken, your assumptions are. Still one mystery remains: 👉 Why exactly NFS behaved that way (never got a perfect answer 😅) #BackendStories #ProductionIssues #Java #NFS

🚨 I didn’t optimize this problem… and that was the right decision. Day 31 of my Backend Developer Journey — and today taught me: 👉 Not every problem needs a complex solution. 🧠 LeetCode Breakthrough Solved today’s challenge using controlled brute force 💡 What clicked: → Compare each query with dictionary words → Count character differences → Accept if differences ≤ 2 ⚡ The real trick: 👉 Break early when condition fails 👉 Keep logic simple and readable 🔍 Key Insight 👉 Sometimes constraints allow brute force 👉 Optimization is useful… but only when needed ⚡ Clean logic > unnecessary complexity 🔗 My Submission: https://lnkd.in/gVDCQx5y ☕ Spring Boot Learning 🏥 Hospital Management System — Project Progress Today I leveled up my project significantly 👇 👉 Created core entities: → Patient → Insurance → Doctor → Appointment 🔗 Real Database Relationships 💡 Implemented real-world mappings: 👉 Patient ↔ Insurance (relationship mapping) 👉 Patient ↔ Appointment 👉 Doctor ↔ Appointment ⚡ This is where backend becomes real: 👉 Not just tables… but connected data systems 🔥 Big Realization 👉 Designing relationships is harder than writing APIs 👉 Good schema design = scalable backend 🧠 The Shift 👉 Simplicity in DSA + Complexity in System Design 👉 Moving from coding → engineering thinking 👉 Building something real changes everything 📘 Spring Boot Notes: https://lnkd.in/gpWQvkyK 🔗 GitHub Repo (Project): https://lnkd.in/gWb8ZPdv 📈 Day 31 Progress: ✅ Practiced clean brute-force logic ✅ Designed real-world DB relationships ✅ Strengthened project-building mindset 💬 What’s harder according to you — DSA problems or designing real systems? 👇 #100DaysOfCode #BackendDevelopment #SpringBoot #Java #LeetCode #SystemDesign #CodingJourney

🚨 Claude Code shipped something I've been wanting for a while: Routines🚨 . If you've been using Claude Code and juggling your own cron jobs, GitHub Actions, and half-broken shell scripts just to get it to run on a schedule… yeah. That whole setup is gone now. Here's the breakdown of what's actually in it: 🚨 Scheduled routines Give it a prompt + a cadence (hourly / nightly / weekly), and it just runs. Example from their post: "Every night at 2am, pull the top bug from Linear, attempt a fix, and open a draft PR." That's a full junior-dev loop running while you sleep. 🚨 API routines Every routine gets its own endpoint and auth token. POST to it, get a session URL back. This is the one that unlocks real integrations — wire it into Datadog, your CD pipeline, PagerDuty, an internal tool, whatever speaks HTTP. 🚨 Webhook routines (GitHub first) Subscribe to a routine to repo events, and it spins up a session per PR. It keeps that session alive, too, so when CI fails or someone leaves a comment, the same session picks it up. Not a one-shot. Runs on Claude's web infra Not your laptop. Not a server you have to babysit. Your machine can be closed, and the work still happens. Some of the use cases they called out that I think are the most interesting: • Nightly backlog triage + Slack summary • Deploy verification that posts go/no-go to the release channel • Alert triage where Claude has a draft fix ready before the on-call even opens the page • Porting changes from a Python SDK to a Go SDK automatically on merge • Custom PR review checklists running before a human looks The thing that stands out to me isn't any single feature — it's that the ceiling on "what should I automate" just went up. Cron + a scratch shell script is a very different thing than a scheduled AI agent that has your repo, your connectors, and your auth. Available now on Pro, Max, Team, and Enterprise (with daily caps — 5 / 15 / 25 respectively). Curious what everyone's going to build with the webhook side of this. The "one session per PR, keeps receiving updates" design is the part I'm going to be playing with first. https://lnkd.in/d6sHFj7x #ClaudeCode #Anthropic #AIAgents #DeveloperTools #Automation #DevOps #SoftwareEngineering

🚀 08/04/26 — Stack Foundations: Balancing Parentheses with Precision Today was a productive session where I successfully implemented the Valid Parentheses (LeetCode 20) challenge. This problem is a fundamental exercise in using the Stack data structure to manage nested relationships and maintain order-based logic. 🧱 The Valid Parentheses Logic The goal is to determine if an input string containing (, ), {, }, [ and ] is valid based on whether every open bracket is closed by the correct type and in the correct order. The Stack Strategy: Pushing: As I iterate through the string, whenever I encounter an opening bracket—(, {, or [—I push it onto the stack. Popping and Matching: When I encounter a closing bracket, I first check if the stack is empty. If it is, the string is invalid. Otherwise, I pop the top element from the stack and compare it to the current closing bracket. Validation: If the brackets don't match (e.g., a ) following a {), the function immediately returns false. Final Check: After the loop finishes, the string is only valid if the stack is completely empty, ensuring all open brackets were properly closed. Complexity Metrics: Time Complexity: O(n) where n is the length of the string, as we perform a single linear pass. Space Complexity: O(n) in the worst case where the string contains only opening brackets, requiring them all to be stored in the stack. 📈 Consistency Report Coming off my 50-day streak milestone, today's focus on stacks feels like a solid pivot from the sliding window and array patterns I've been mastering recently. The logic used here is remarkably similar to the structural checks I used in the "String Search" and "Mountain Array" problems earlier this month, where maintaining a specific state across iterations was key. Huge thanks to Anuj Kumar (a.k.a CTO Bhaiya on YouTube) for the continuous inspiration. Every new data structure I master adds another layer to my problem-solving toolkit! My tested O(n) stack-based implementation is attached below! 📄👇 #DSA #Java #Stack #ValidParentheses #DataStructures #Complexity #Consistency #LearningInPublic #CTOBhaiya

🧪 #PythonJourney | Day 149 — Testing API Endpoints & Validating Backend Today was about validating that everything works end-to-end. After days of building, it was time to test the actual API with real requests. Key accomplishments: ✅ All 8 API endpoints are functional:   • POST /api/v1/urls (create shortened URL)   • GET /api/v1/urls (list user's URLs)   • GET /api/v1/urls/{id} (get URL details)   • GET /api/v1/urls/{id}/analytics (get analytics)   • DELETE /api/v1/urls/{id} (soft delete)   • GET /{short_code} (redirect & track)   • GET /health (health check) ✅ Database integration fully operational:   • User authentication via API key works   • URL creation with validation   • Click tracking with proper foreign keys   • Analytics aggregation ready ✅ Docker environment stable:   • PostgreSQL 15 storing data correctly   • Redis 7 ready for caching   • FastAPI container running smoothly   • All services healthy ✅ Tested with curl:   • Health check endpoint responds   • API authentication working   • Request/response validation functioning   • Error handling in place ✅ Code committed to GitHub:   • Clean commits with meaningful messages   • Full project history tracked   • Ready for collaboration What I learned today: → End-to-end testing reveals integration issues early → API key authentication is simple but effective → Docker composition makes local development seamless → Curl is a powerful tool for API testing → Validating one endpoint at a time saves debugging time The backend is now production-ready in terms of basic functionality. Next: comprehensive testing with pytest and then deployment. Current status: - Backend: ✅ Functional - Database: ✅ Operational   - API Endpoints: ✅ All working - Docker: ✅ Stable - Tests: ⏳ Next step - Deployment: ⏳ After tests #Python #FastAPI #API #Testing #Backend #Docker #PostgreSQL #SoftwareDevelopment #DevOps