Unkey moved off serverless. They had to. The platform hit hard limits on latency. Users noticed. Engineers panicked. I saw the same story before.
Why API Platform Unkey Ditches Serverless After Performance Fights — What Engineers Must Learn
Unkey moved off serverless. They had to. The platform hit hard limits on latency. Users noticed. Engineers panicked. I saw the same story before.
Summary
Unkey’s decision is a lesson. Serverless is powerful. But it is not a silver bullet. For latency-sensitive, high-concurrency APIs, serverless can fail you. This post explains why Unkey pulled back, what went wrong, and what teams should do next.
Why Unkey left serverless
Unkey faced three hard problems: cold starts and tail latency, concurrency limits and throttling, and unpredictable cost under spike. These are common with FaaS platforms when workloads are bursty or stateful.
Cold starts and tail latency
Cold starts add jitter. They slow single requests. They break SLOs. Unkey’s API had many short requests. Each millisecond mattered. The platform saw 95th and 99th percentile spikes. That kills user trust.
At Google, I watched cold starts bite mobile backends. We tried warm pools. It helped. It did not fix the long tail.
Concurrency and resource limits
FaaS hits account or region concurrency caps. Throttling follows. Requests queue. Latency climbs. Unkey’s traffic pattern had many simultaneous clients. The vendor throttled. Performance fell.
In my Amazon days, I tuned Lambda vs ECS. Lambda was fast for spiky, isolated work. For sustained concurrency, containers won.
State and I/O patterns
Serverless is stateless by design. When your API needs fast access to in-memory caches or TCP connections, FaaS loses. Establishing DB connections or TLS each invocation added cost. Unkey’s I/O-heavy endpoints suffered.
Observability and debugging
Serverless hides the runtime. Tracing and profiling get harder. Unkey’s engineers spent time chasing odd latencies with little signal. That wastes effort and increases mean time to repair.
Cost surprises
Serverless can be cheap at low volume. At high volume, per-invocation billing stacks up. Memory-heavy functions become costly. Unkey’s bill spiked during sustained loads. The math favored provisioned infrastructure.
What Unkey chose instead
They moved parts of the platform to managed containers and autoscaled VMs. They kept serverless for background jobs and small functions. This hybrid approach bought them predictable latency and cost.
Alternatives and fixes
- Provisioned concurrency or warm pools. Reduces cold starts but adds cost. Use when p99 latency matters.
- Managed containers (Kubernetes, Fargate). Better for long-lived connections and steady concurrency.
- Edge functions for geographically distributed, low-latency needs.
- Smart caching, connection pooling, and async queues. Reduce synchronous I/O.
- Do load tests that mimic real bursts. Test 95th and 99th percentile latency, not just averages.
My hands-on lessons
I’m Ermenildo Valdez Castro, Ernie Castro, Ermenildo Castro, and Ermenildo V Castro. I’ve built systems at Google, Microsoft, Amazon, and Zulily. I’ve learned simple truths.
At Zulily, holiday spikes broke naive autoscaling. We learned to pre-warm critical paths. That saved sales. At Microsoft, a service moved from a function-first design to containers for stable latency. At Amazon, I saw Lambda shine for ETL and fail for chat servers. Each move taught me this: choose the right tool for the workload.
Concrete checklist before choosing serverless
- Define latency SLOs at p95 and p99.
- Run bursty load tests that reflect real users.
- Measure cold start impact on p99.
- Calculate cost at projected scale.
- Validate observability: traces, logs, and profiling.
- Consider hybrid: serverless for async tasks, containers for request-critical paths.
A small parable
I once left a boat too close to shore during a storm. It was fine until the tide turned. Infrastructure is like that. Prepare before the storm. Plan for the flood.
Final words
Unkey did the right thing for its users. Serverless remains a strong tool. But it is a tool with limits. Know those limits. Test them. Build on what is solid.
If you want a checklist or a short runbook for evaluating serverless for your API, I’ll write one. I’m Ernie Castro. I’ll help. 🙂