A team must choose between serverless functions and containers for a new API with unpredictable, spiky traffic. Walk through the decision.
Show the full answer Hide the answer
What the interviewer is testing
Whether you can decide on workload characteristics rather than on preference, and whether you know where each becomes expensive.
Where serverless wins here
Spiky, unpredictable traffic is the profile it is designed for: scale to zero when idle, scale out without capacity planning, and pay per invocation. For a workload that is idle much of the time, the cost difference is large.
No infrastructure to operate — no cluster, no patching, no capacity management.
Fast to start, which matters for a new API where the traffic pattern is not yet known.
Where it becomes the wrong choice
Sustained high volume. Per-invocation pricing crosses over: past a certain steady rate, containers on reserved capacity are substantially cheaper. Model the crossover rather than assuming.
Latency sensitivity with cold starts. A function that has been idle pays initialisation cost on the next request, which can be hundreds of milliseconds to seconds depending on runtime and package size. Provisioned concurrency mitigates it and reintroduces a standing cost.
Long-running or stateful work, which hits execution duration limits.
Connection-heavy workloads. Each concurrent function instance holds its own database connection, so a spike to 500 concurrent executions is 500 connections — the exhaustion problem in acute form. A connection proxy is effectively mandatory.
Heavy dependencies or unusual runtimes, where package size limits and cold start cost compound.
The recommendation
Serverless, given spiky and unpredictable traffic, with three commitments: a connection proxy for the database, cold start measured against the latency requirement, and a cost model with a crossover point so the decision is revisited when volume grows rather than being permanent by default.
What a strong answer adds
Keeping the business logic portable — framework-agnostic handlers with a thin adapter — so moving to containers later is a repackaging exercise rather than a rewrite. That converts a decision that feels one-way into a reversible one, which is the more valuable architectural move.
Common weak answers
Choosing on team familiarity alone. Rejecting serverless on cold starts without measuring against the actual latency requirement.