API performance problems fall into two categories: the ones that appear immediately during development and are fixed before they matter, and the ones that are invisible during development and catastrophic at production scale. The second category is where the interesting work is. Understanding where APIs slow down under load — and the specific techniques that address each cause — is the difference between an API that performs at scale and one that requires emergency remediation after launch.

APIs are contracts. When you publish an API and someone builds an integration against it, they are betting their system on your endpoint continuing to behave as documented. Versioning is how you preserve that contract while still being able to evolve the underlying system. Done well, it gives you forward momentum without leaving integrators behind. Done poorly, it creates a maintenance burden that accumulates until one side gives up.

What Counts as a Breaking Change

The most important skill in API versioning is recognizing what requires a version increment. A breaking change is anything that causes a previously valid, working integration to fail or behave differently without modification. This is a broader category than most developers initially assume.

HTTP is a synchronous protocol. A client sends a request and waits for a response. This works well for operations that complete in milliseconds — a database read, a record update, a validation check. It breaks down for operations that take seconds, minutes, or longer: video transcoding, report generation, bulk data exports, machine learning inference on large inputs, email campaigns to millions of recipients.

Holding an HTTP connection open for a minute or more is technically possible and practically wrong. Clients time out. Load balancers have maximum request durations. Users cannot tell the difference between a server still working and a server that silently failed. Long synchronous operations produce brittle integrations and poor user experiences.

HTTP was designed from the beginning to support multiple representations of the same resource. A user profile can be represented as JSON for a machine consumer or as HTML for a browser. A dataset can be returned as JSON or as CSV depending on what the client intends to do with it. An image can be served as JPEG or WebP based on what the browser supports. Content negotiation is the mechanism through which clients and servers agree on which representation to use — and understanding it is essential for building APIs that serve diverse consumers cleanly.

CORS is the source of more developer frustration than almost any other browser security mechanism — not because it is poorly designed, but because its error messages are opaque, its rules are non-obvious, and it only manifests in a specific context that server-side developers often do not encounter during development. Understanding what CORS actually is and why it exists transforms it from an arbitrary obstacle into a predictable system with clear rules.

File handling is where many otherwise well-designed APIs cut corners. The result is integrations that work fine for small files and break under production conditions: uploads timing out on slow connections, downloads failing midway through large transfers, clients with no way to resume an interrupted operation. File upload and download have well-established patterns that handle these conditions correctly. Most of them require explicit design choices rather than the defaults.

Simple Upload: When It Is Sufficient

For files under a few megabytes that users upload infrequently, a direct multipart form upload to your API is the simplest approach. The client sends a multipart/form-data POST request with the file as one part and any metadata as additional parts or as a separate JSON field:

Caching is one of the highest-leverage performance improvements available to an API, and one of the least consistently implemented. A response that is cached at the right layer — in a CDN, a reverse proxy, or the client itself — eliminates a server round trip entirely. At scale, that elimination compounds: fewer database queries, lower infrastructure cost, faster responses for every consumer. The HTTP specification provides a complete, standardized caching system. Most APIs use it only partially, leaving significant headroom unrealized.

Networks fail. Connections drop. Load balancers time out. Servers restart mid-request. In a distributed system, any request that travels over a network can be sent but not confirmed, leaving the caller uncertain whether the operation completed. This is not a rare edge case — it is a routine condition that well-designed APIs must handle. Idempotency is the mechanism that makes retrying safe when certainty is unavailable.

What Idempotency Means

An operation is idempotent if performing it multiple times produces the same result as performing it once. The outcome is identical whether you call it one time or ten times; subsequent calls do not change anything that the first call already changed.