Is EES meltdown really an app performance problem?

A few weeks ago I stood at a passport kiosk in Malaga airport, watching a little hourglass spin. The screen said "WAITING FOR AUTHORIZATION". It said it for a long time.

This is the EU's new Entry/Exit System (EES), and as I stood there watching that hourglass I had the uncomfortable realisation that I have debugged this exact failure before. Not at a border. In web apps. The screen in front of me was a textbook performance problem, just with a passport instead of a page load.

So let's ask the question seriously: is the EES "meltdown" really an app performance problem? The answer is mostly yes, and the reason is arithmetic.

What EES actually is

EES is the EU's biometric border system. It replaces the manual passport stamp for non-EU travellers on short stays with a digital record: your document is scanned, your face is photographed, your fingerprints are captured, and you fill in a short form. It began a phased rollout on 12 October 2025 and became mandatory across all 29 Schengen countries on 10 April 2026.

Before any of that, though, the kiosk asks for your consent. There is a screen, in the finest tradition of the web, that reads: "Do you consent to the collection and processing of your personal data for the purposes of border management and prevention of irregular immigration... according to art. 50.4 and 5 EU Regulation 2017/2226?" with two buttons, YES and NO. The cookie banner has officially escaped the internet and reached the physical border. Fly a thousand miles and you still have to click "I accept", except here NO is not really on the table.

The scale of the meltdown

Since full enforcement on 10 April 2026, major European airports have seen border queues of two to four hours. ACI Europe reported processing times up by as much as 70% at peak traffic, though that figure is location-specific and peak-weighted rather than universal. The knock-on effects made the news: at Milan Linate, an easyJet flight that should have carried 156 passengers reportedly boarded only 34, leaving the rest stranded; at Toulouse, more than 150 passengers missed a Ryanair departure to London. The airline industry group A4E publicly called it a "systemic failure" rather than teething problems, and several carriers asked for EES to be temporarily suspended before the summer peak.

To be fair to the system, some of this is a transition cost. The first time you cross, you enrol; on later trips the registration is already on file and the process is meant to be quicker. But that does not explain the queues, and it does not get the system off the hook. Because the queues are not really about any one traveller. They are about the maths of all of them at once.

The spec knew this would happen

Here is the uncomfortable part. The EU wrote down a throughput limit for exactly this, years ago, and then sailed past it.

Back in 2015, eu-LISA's own Smart Borders Pilot tested biometric border crossings and set a plain threshold: anything under 30 seconds per traveller was the limit "beyond which there would be an impact on the queue at a border control in an airport", and anything over 60 seconds meant the system would be "unlikely to be able to provide sufficient throughput". Measured enrolment in that pilot ran from 17 seconds for four fingerprints to around 60 for ten. The Commission's own 2026 line is that registration "takes on average only 70 seconds" at full capacity, and Spain's border preparation targeted 160 passengers per kiosk per hour, which works out to roughly 22 seconds each.

So the target was always tens of seconds. The "WAITING FOR AUTHORIZATION" wait alone is a minute or two. That is not a small overrun, it is multiples of the design budget, and the throughput maths below is what turns that overrun into a three-hour queue.

The EES Regulation itself (2017/2226, Article 37) requires the system to run "24 hours a day, 7 days a week... at a satisfactory level of operational quality, in particular as regards the response time for interrogation of the EES Central System by border authorities". It names response time as a quality criterion but never puts a number on it in public. The only hard, published performance figures in the spec are biometric accuracy rates, not speed. France, for what it is worth, paused its rollout at the Channel after the biometric software failed its final performance and acceptance tests, so somebody was at least checking.

The core argument: it is arithmetic

Here is the part performance engineers feel in their bones.

Even a quick, well-prepared traveller needs roughly one to two minutes for the kiosk itself: scan the document, capture the face, take the fingerprints, complete the form, accept the consent banner. That is the human part, and it has a real floor. You cannot wish it to zero.

Then the kiosk sends your data off to a central system to be authorised, and you get the hourglass. That wait adds another minute or two on top.

Adding one to two minutes onto a one-to-two-minute baseline roughly doubles the time each traveller spends at the kiosk. And if each person takes twice as long, each kiosk processes half as many people per hour. A booth that could clear around 40 travellers an hour at 90 seconds each clears roughly 20 an hour at 180 seconds. Same kiosk, same border guard, half the throughput.

Halved throughput is where the queues come from. A wide-body aircraft empties a few hundred people into the hall in minutes. When the arrival rate is higher than the rate the kiosks can clear, the queue does not just get a bit longer, it grows without bound, and the backlog compounds flight after flight. This is basic queueing theory: as utilisation approaches 100%, waiting time does not rise gently, it explodes. Halving the service rate is exactly the kind of change that tips a system from "fine on a normal Tuesday" into "three hours on a Saturday in July".

If you build web applications, you already know this shape. It is per-request latency multiplied by concurrency. Bolt a slow 90-second dependency onto a request that already took 90 seconds and you have halved how many requests you can serve. The queue backs up in precisely the same way a thread pool does when every request suddenly takes twice as long. And the fix is the same too: you do not necessarily need more servers, you need the slow call to be faster.

Where it is not purely an app problem

It would be dishonest to pin all of this on software, so let's be clear about what you cannot engineer away.

• Biometric capture has a physical floor. Photographing a face and reading ten fingerprints takes real seconds, and no amount of clever code removes them.
• The authorization is a genuine dependency. For security and legal reasons the kiosk has to actually check against the central system. You cannot optimistically wave someone through and reconcile later, the way you might with a non-critical web request.
• Staffing and kiosk counts are real levers too. But notice they only scale linearly: adding a booth adds one lane. Cutting the per-traveller time speeds up every lane at once. That is why it is the higher-leverage fix.

And plenty of the early chaos was plain operational: reports from the worst-hit airports describe e-gates switched off, booths left unstaffed, and rows of kiosks sitting idle while two officers worked a queue of hundreds. That is a deployment failure, not a software one, and it made everything worse. But it sits on top of the throughput problem rather than replacing it. Even a perfectly staffed hall is in trouble if every traveller takes twice as long as the system was sized for.

So no, it is not only an app performance problem. But the single biggest, most leverage-rich chunk of the delay, the authorization wait, is squarely the kind of thing performance engineering exists to attack.

What a performance engineer would actually do

Faced with this in a web app, the playbook is well worn:

• Attack the slow call first. The authorization round-trip is the highest-leverage number in the whole system. Everything else is downstream of it.
• Precompute it. Let people enrol their biometrics before they travel, so the slow step is already done on arrival. This is just warming the cache so the expensive work is not on the critical path.
• Parallelise. Capture the fingerprints and face while the authorization call is in flight, not in a strict series after it. Do not make the human wait and then make them wait again.
• Provision for peak, not average. The summer rush is a known date on a calendar. You load-test for Black Friday; you size a border system for August.

Interestingly, the EU built itself one more escape hatch: the legal framework lets member states partially suspend EES checks for up to 90 days, with an optional 60-day extension, to relieve queues. That is load-shedding. It is the border-control equivalent of feature-flagging an expensive code path off when traffic spikes. Useful as a tourniquet, but it is a way of turning the slow thing off, not making it fast.

Key takeaways

• The queues are arithmetic, not bad luck. The authorization wait roughly doubles the time per traveller, which roughly halves throughput, and halved throughput is what becomes a three-hour queue.
• That extra time is mostly the "WAITING FOR AUTHORIZATION" backend round-trip. It is an app performance problem with a passport.
• It is not purely software. Biometric capture has a physical floor and the backend check is a real dependency. But the highest-leverage part of the delay is squarely engineerable.
• The universal lesson holds for any business: a slow per-transaction call is invisible at low volume and catastrophic at scale. Cut the call time and the queue clears itself, on the same hardware.

We spend our days finding the one slow call that is quietly halving someone's throughput, whether that is a checkout, an API, or an internal tool that makes staff wait. If your next launch or peak event risks the same failure mode, get in touch. We would rather help you size it before the queue forms than diagnose it after.