One of the most important performance lessons I learned early in my career is this: network calls are expensive. Using the internet to retrieve or send data introduces latency, instability, and unpredictability—often becoming the biggest performance bottleneck in modern apps. That’s why I’ve long preached in my talks and books:

Avoid going across the wire (network) until necessary—and batch calls as much as possible!

Chunky, Not Chatty

In my coding standards book, I emphasize building services that support chunky, not chatty, communication. That means fewer, more comprehensive calls instead of flooding your APIs with small, repetitive requests. The fewer times you cross the wire, the better your app will perform—especially in global deployments where internet routing can be wildly inconsistent.

Real-World Lesson: API Development & Partner Reviews

At one company, I was tasked with developing their first API, built with Entity Framework and WCF Data Services. The goal was to allow partners to retrieve critical business data. As part of the onboarding process, I created a code review system that was mandatory for every partner integration, regardless of programming language.

I personally reviewed most of the submitted code, and my top concern was ensuring batching and efficient data retrieval. I rejected many early implementations because they didn’t meet our performance standards—they were too chatty, flooding the API with small requests and harming performance. I wasn’t doing this to be a gatekeeper; I was teaching partners how to use the API effectively and sustainably.

Distance ≠ Speed

Every morning, I’d analyze API call performance reports from across the U.S. That’s when I learned just how unpredictable the internet really is. Despite our servers being located in San Diego, California, I noticed something shocking:

• Calls from Florida, over 2,300 miles (3,700 kilometers) away, were often faster than those from Los Angeles, which is only 120 miles (193 kilometers) away.

Let that sink in: a call traveling 30 times farther was completing faster. That’s when I fully understood that internet routing, peering agreements, and ISP infrastructure are often the real bottlenecks—not the physical distance.

That experience cemented my rule: never assume network performance is logical or reliable. Always batch when possible.

Monitoring, Enforcement & Optimization

To maintain performance standards, I added comprehensive logging and reporting to track partner API usage. If a partner’s live app started spamming the API with chatty calls, I could catch it—and I had the authority to temporarily revoke access after appropriate warnings.

Partners who followed best practices and used batching correctly saw faster results and better throughput. This not only improved performance but also reduced operational costs for both sides. Everyone won—when they followed the rules.

Developers: Own the Whole Stack

Too often, developers obsess over frontend or backend speed while ignoring the network entirely. I’ve seen web pages that make over 100 API calls just to load, which is absurd.

The reality is: performance isn’t just a backend thing or a frontend thing—it’s an end-to-end discipline. And the network is often your weakest link if you don’t design around it.

Summary: Respect the Wire or Regret It

Network calls are often the hidden killers of application performance. As shown through real-world experience and performance data, even short distances can suffer from poor latency due to unpredictable routing. By designing chunky APIs, using batching, and monitoring real-world performance, developers can avoid the trap of chatty, laggy applications.

The lesson is simple but vital: treat every trip across the wire as a liability—batch it, minimize it, and always design around it.

Pick up any books by David McCarter by going to Amazon.com: http://bit.ly/RockYourCodeBooks

If you liked this article, please buy David a cup of Coffee by going here: https://www.buymeacoffee.com/dotnetdave

© The information in this article is copywritten and cannot be preproduced in any way without express permission from David McCarter.