When Order Isn’t Needed: Why Idempotent APIs Should Consider UDP

In the world of web services, TCP has long been the default bearer of reliability. Its guarantees—ordered delivery, retransmission of lost packets, and connection‑oriented communication—make it a natural fit for APIs that need to ensure every request reaches the server and every response reaches the client.

But what if the API’s contract is idempotent? If a client can safely repeat a request without altering the outcome, the strict ordering that TCP enforces may be an overkill, turning a simple “get my ticket” into a bottleneck.

The Amphitheater Analogy

The article uses a vivid analogy: a bustling amphitheater with two ticket windows.

1. The Reliable Window – a long line, each person waiting for the cashier to finish the previous transaction. The system guarantees order and completion before moving on. When a customer pays in pennies, the line stalls, and the entire queue must reorganize.
2. The Walk‑Up Service – no line. Patrons shout their name, receive a ticket almost instantly, and continue walking. If the request fails, they simply try again later.

“Reliability isn’t about guaranteeing order when order doesn’t matter. It’s about guaranteeing you get what you need.”

This narrative illustrates head‑of‑line blocking: a single slow or stalled request can stall the entire queue of TCP connections. In contrast, the walk‑up model—analogous to UDP—lets each request proceed independently, retrying only if necessary.

Technical Implications

Head‑of‑Line Blocking

TCP’s connection‑oriented nature means that if a packet is lost, the entire stream waits for retransmission. In a high‑traffic API, a single lost packet can stall all subsequent requests on that connection.

Load Shedding

When a server is overloaded, new TCP connections may fail to establish, and existing connections can become stuck waiting for packets that never arrive. UDP, lacking a connection handshake, simply drops packets that cannot be processed, allowing well‑behaved clients to retry and recover gracefully.

Idempotency as a Design Choice

If an API guarantees that repeated requests produce the same result—such as issuing the same ticket or returning the same resource—then ordering is no longer a safety requirement. Developers can remove the overhead of connection establishment, flow control, and retransmission, and instead focus on delivering quick responses and allowing clients to retry.

When UDP Makes Sense

• Fast, low‑latency services where the cost of a lost packet is outweighed by the benefit of immediate delivery.
• Stateless, idempotent endpoints where retries are safe and inexpensive.
• High‑scale environments where head‑of‑line blocking and connection churn can become performance bottlenecks.

In such scenarios, a UDP‑based gateway can provide a lightweight, resilient interface that maintains the illusion of reliability without the heavy machinery of TCP.

A Call for Nuanced Reliability

Reliability is not a one‑size‑fits‑all property. Understanding the specific guarantees your API needs—and the trade‑offs of each transport protocol—enables engineers to choose the right tool for the job. For idempotent APIs, UDP can often deliver superior performance and resilience.

Source: Proxylity, “Reliability and Idempotency,” https://www.proxylity.com/articles/reliability-and-idempotency.html