Admission Handshake

When a program wants something from a server on the internet, it sends off a request. But the server only has limited computing power and cannot process an unlimited number of requests at the same time. In an admission handshake, one side therefore first briefly asks: Do you currently have room for me? The other side answers with Yes, No, or “wait a moment.” Only after this short preliminary exchange is the actual data sent. The English term “handshake” means exactly that: a mutual confirmation before things get started.

Why servers prefer to say No in advance

Without such a preliminary exchange, a server accepts every request, even if it is already overloaded. It then processes hundreds of jobs at once, but all at a crawl. In the end, all users wait too long, and many give up. The work was for nothing, and the computing time has been used up. Experts call this a collapse under load.

A fast rejection is better for everyone than a slow maybe. Anyone who gets an immediate No can try again a second later or switch to another server. Meanwhile, the requests that were accepted run through at normal speed. So a small portion of requests is sacrificed in order to save the rest.

This is especially important for AI services. A single response from a large language model — that is, a program that generates text — can occupy many seconds of computing time on expensive specialized hardware. This hardware is called a GPU and is scarce and costly. Anyone who clogs it up with requests that no one is waiting for anymore is burning money.

What is exchanged in the preliminary conversation

In the first step, the requester states what it intends to do. Typical details include: how much text it wants to send, how long the response should be, and how long it can wait at most. This can be compared to checking in at the airport. First it’s checked whether the baggage weight and ticket match, then you’re allowed through.

In the second step, the service checks its own state. It looks at how many jobs are already running, how full the queue is, and how much memory is free. Often it additionally calculates whether it can meet the promised waiting time. It then responds with an approval, a rejection, or a place in the queue.

An approval can also come with conditions. For example, the service releases a time window or a token, meaning a digital authorization slip for that one specific request. Anyone who arrives without a valid token is turned away. It is important to distinguish this from a rate limit: a rate limit rigidly caps the number of requests per minute, whereas the admission handshake decides situationally based on current load.

Where the term appears in reports and products

It is most often read about in technical descriptions from cloud providers, i.e., companies that rent out computing power. Operators of AI interfaces also describe in this way how they cushion load spikes. When a provider states that requests come back with an error code and a recommended waiting time during overload, this is exactly the principle behind it.

As a user, you notice it indirectly. A chatbot that, under heavy demand, reports “Please try again later” has not accepted the request at all. That is unpleasant, but more honest than a response that cuts off after two minutes. Video conferencing and online games also use similar admission checks before establishing a connection.

For investors and analysts, this topic is interesting because it directly affects costs. A provider with good admission control gets more usable responses out of the same hardware. Incidentally, a common misconception is that the handshake makes the system faster. It mainly makes it more reliable — the individual request does not gain any computing power as a result.