sharath odepalli

  How “Calls per Request” helps you catch hidden performance and cost bugs early Most “slow apps” are not slow because the database is bad. They are slow because a single request quietly triggers far more work than anyone expects. This pattern is commonly known as  N+1 queries , but in real systems it goes beyond databases. It becomes  N+1 work . And once it shows up, it hurts performance, reliability, and cloud cost at the same time. This blog explains what N+1 work looks like, why it is dangerous, and how to prevent it using one simple measurement:  calls per request . 1) What N+1 work actually is N+1 happens when something that should happen  once  happens  N times , usually because it sits inside a loop. A classic example: You fetch 100 orders. For each order, you fetch customer details. That becomes 1 query for orders + 100 queries for customers. But the same pattern appears outside the database too: One API request triggers 1 service call, then 3...

Most teams do not have a productivity problem. They have a visibility problem. That might sound like a soft, management-style statement. But it shows up in the most technical places: PR queues, release pipelines, QA loops, incident ownership, and the silent gap between “merged” and “actually working in production.” When work is invisible, teams feel busy all day and still ship slowly. Not because they are not working, but because the system hides where time is being lost. This blog is about making work visible, so delivery becomes predictable. The lie we tell ourselves about “done” Many teams define “done” like this: A developer finished the implementation. But software does not create value when it is implemented. It creates value when it is deployed, used, and stable. A more honest definition of done is: Built Reviewed Tested Released Observed in production Confirmed to work and create value If your board stops at “Done” after code is written, you are tracking activity, not outcomes....

Most of us debug too late. Not because we are lazy or slow. But because we treat debugging as something we do after a failure, not something we design for before shipping. I used to think reliability was about writing “better code.” Over time I learned a harder truth: Reliable systems come from better questions. A small habit changed how I build features. Now, before I ship anything, I force myself to answer three questions. They sound simple, but they prevent a surprising number of real incidents. The 3 Questions 1) What will fail first? Every feature has a weak point. It might be: An external API timing out A database query that becomes slow under load A queue consumer that stops processing A dependency that rate-limits unexpectedly A configuration value that is correct in staging but wrong in production The mistake is assuming failure will be rare. Failure is normal. The only question is where it will show up first. When you ask “what fails first,” you stop thinking like a builder a...