DEV Community: Dipendra Neupane

Before you blame EF Core for a slow API, check this.

Dipendra Neupane — Sat, 17 Oct 2026 03:12:29 +0000

"The query is slow" is one of the most common misdiagnoses I see. Often, the query is fine, and the problem lies elsewhere. Next time you hit a slow endpoint, check these too.

⚡𝗧𝗵𝗿𝗲𝗮𝗱 𝗽𝗼𝗼𝗹 𝘀𝘁𝗮𝗿𝘃𝗮𝘁𝗶𝗼𝗻

You call DoSomethingAsync() and then block on it with .Wait() or .Result. That thread now sits there waiting, and another thread from the pool may be needed to finish the async work.

Under a burst of requests, this quickly eats up thread pool threads, and the whole API slows down, not just that endpoint.

⚡𝗖𝗼𝗻𝗻𝗲𝗰𝘁𝗶𝗼𝗻 𝗽𝗼𝗼𝗹 𝗲𝘅𝗵𝗮𝘂𝘀𝘁𝗶𝗼𝗻

Quite similar to thread pool starvation, but for database connections. Once the app has used up every available connection, new requests have to wait for one to free up. The query itself might take 5ms, but the request waits seconds before it even runs.

Common causes: connections or DbContexts not disposed properly, long-running queries, or a pool size that's too small for your load.

⚡𝗟𝗼𝗰𝗸𝗶𝗻𝗴 𝗮𝗻𝗱 𝗯𝗹𝗼𝗰𝗸𝗶𝗻𝗴

Locking is normal. SQL Server locks data while a transaction works with it, so another transaction can't make a conflicting change at the same time.

Blocking is when another transaction has to wait for that lock. A little is fine. It becomes a problem when a transaction holds the lock for too long, and your "slow" query is really just stuck in a queue.

⚡𝗦𝗲𝗿𝗶𝗮𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻

Turning a large or deeply nested object into JSON takes time. Returning entities directly is a common trap because navigation properties can pull in huge object graphs. Return DTOs with only what the client needs.

⚡𝗛𝗶𝗱𝗱𝗲𝗻 𝗽𝗲𝗿-𝗿𝗲𝗾𝘂𝗲𝘀𝘁 𝘄𝗼𝗿𝗸

Before a request reaches your controller, it may already go through logging, tracing, auth checks, and other middleware. After the controller, there's serialization, response logging, and so on.

Most of this is necessary. But an expensive logging setup or one extra DB call in an auth handler runs on every single request. Know what happens before and after your code runs.

There's still plenty to tune inside EF Core itself. But knowing where else time goes is what makes debugging faster.

What's the strangest cause you've found behind a "slow query"?

I share more engineering notes and production lessons on LinkedIn: Dipendra Neupane.

𝗪𝗵𝗮𝘁 𝘄𝗼𝗿𝗸𝘀 𝗳𝗼𝗿 𝗦𝗶𝗴𝗻𝗮𝗹𝗥 𝗹𝗼𝗰𝗮𝗹𝗹𝘆 𝗰𝗮𝗻 𝗳𝗮𝗶𝗹 𝗶𝗻 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻

Dipendra Neupane — Wed, 14 Oct 2026 12:28:14 +0000

Here's what I've learned while taking SignalR web applications from local development to production.

⚡𝗔𝘂𝘁𝗵 𝘄𝗼𝗿𝗸𝘀 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁𝗹𝘆.

Browsers don't let the client set the Authorization header on the WebSocket handshake, so the access token goes in the query string.

⚡𝗜𝘁 𝗰𝗮𝗻 𝗳𝗮𝗹𝗹 𝗯𝗮𝗰𝗸 𝗳𝗿𝗼𝗺 𝗪𝗲𝗯𝗦𝗼𝗰𝗸𝗲𝘁𝘀 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗯𝗿𝗲𝗮𝗸𝗶𝗻𝗴 𝘆𝗼𝘂𝗿 𝗮𝗽𝗽.

Locally, you may be using WebSockets without realizing it. In production, a missing IIS WebSocket feature can prevent WebSockets from being used.

SignalR can then fall back to Server-Sent Events or Long Polling.

⚡𝗜𝗻𝗰𝗼𝗺𝗶𝗻𝗴 𝗺𝗲𝘀𝘀𝗮𝗴𝗲𝘀 𝗮𝗿𝗲 𝗹𝗶𝗺𝗶𝘁𝗲𝗱 𝘁𝗼 𝟯𝟮 𝗞𝗕 𝗯𝘆 𝗱𝗲𝗳𝗮𝘂𝗹𝘁.

SignalR's maximum receive message size defaults to 32 KB for a single incoming hub message. If it exceeds this limit, SignalR throws an error, and the connection is closed.

You can increase the message size limit, but blindly increasing it will also increase memory usage.

⚡𝗜𝘁 𝘄𝗼𝗿𝗸𝘀 𝘄𝗶𝘁𝗵 𝗼𝗻𝗲 𝘀𝗲𝗿𝘃𝗲𝗿, 𝘁𝗵𝗲𝗻 𝗯𝗿𝗲𝗮𝗸𝘀 𝘄𝗵𝗲𝗻 𝘆𝗼𝘂 𝘀𝗰𝗮𝗹𝗲.

With multiple API instances, each SignalR connection belongs to a specific server. If another instance sends a message, it doesn’t automatically know about the connections on the other servers.

If your SignalR server is running behind a load balancer, plan for cross-server message distribution using a backplane such as Redis or Azure SignalR Service.

The irony is, I switched to Ably after learning all of these hard lessons.

What's the hardest SignalR issue you've hit in production?

I share more engineering notes and production lessons on LinkedIn: Dipendra Neupane.

Webhooks Aren't Notifications. They're Distributed Systems.

Dipendra Neupane — Thu, 08 Oct 2026 18:40:52 +0000

Here are a few lessons I learned while working with Stripe Webhooks in production.

⚡𝗬𝗼𝘂𝗿 𝗛𝗧𝗧𝗣 𝘀𝘁𝗮𝘁𝘂𝘀 𝗰𝗼𝗱𝗲 𝗶𝘀 𝘆𝗼𝘂𝗿 𝗿𝗲𝘁𝗿𝘆 𝗽𝗼𝗹𝗶𝗰𝘆.

Returning 200 tells Stripe the event was received and processed successfully. Stripe won't retry it again.

If your business logic fails, you should return a 5xx status code so that Stripe automatically retries the event delivery

⚡𝗧𝗵𝗲 𝗲𝘃𝗲𝗻𝘁 𝘆𝗼𝘂 𝗿𝗲𝗰𝗲𝗶𝘃𝗲 𝗶𝘀 𝗮 𝗵𝗶𝗻𝘁, 𝗻𝗼𝘁 𝘁𝗵𝗲 𝘁𝗿𝘂𝘁𝗵.

Webhook events may arrive late or out of order. Don't trust the payload. Refetch the current state from a source of truth and act accordingly.

⚡𝗗𝗼𝗻'𝘁 𝗱𝗼 𝘀𝗹𝗼𝘄 𝘄𝗼𝗿𝗸 𝗶𝗻𝘀𝗶𝗱𝗲 𝘁𝗵𝗲 𝗪𝗲𝗯𝗵𝗼𝗼𝗸 𝗲𝘃𝗲𝗻𝘁.

Stripe has a timeout threshold. If the endpoint doesn't respond quickly enough, Stripe considers it a failure and retries.

Process the slow work asynchronously outside the webhook handler.

Do you have any hard-learned lessons about Webhooks or Stripe? I'd love to know about that.

I share more engineering notes and production lessons on LinkedIn: Dipendra Neupane.