A video analysis pipeline splits streams into frames, analyses each, and aggregates. Built as serverless functions passing frames through object storage, it costs far more than expected. Diagnose.

What the interviewer is testing

Whether you can identify that the cost is in the boundaries rather than in the work.

The diagnosis

The data movement dominates the computation.

Consider the volume: a video stream produces many frames per second, and each one is written to object storage by one component and read back by the next. Every frame therefore costs a write request, a read request, storage, and the latency of both — and every step transition costs an orchestration state change.

The analysis of a single frame is cheap. The overhead of moving it between components is not, and it scales with frame count, which is the largest number in the system.

This is a general property: distribution has a per-boundary tax, and that tax scales with chattiness. A pipeline exchanging high volumes of small intermediate results at high frequency is the worst possible shape for a distributed design.

The fix

Consolidate the pipeline stages into a single process so that frame handoffs become in-memory function calls rather than storage round trips. The work is unchanged; the overhead disappears.

Amazon's Prime Video team published exactly this: moving their audio and video quality monitoring from distributed serverless components to a monolith running on container instances, reporting a cost reduction of over 90%.

The nuance that matters

This does not generalise to "microservices are expensive". It generalises to a boundary-placement rule: distribution boundaries should follow change and ownership, not diagram aesthetics.

The stages of this pipeline always run together, always scale together, are owned by one team, and pass large volumes of intermediate data. There is no independence benefit to buy, so every network hop is pure cost.

What a strong answer adds

The diagnostic to apply to any boundary: what data crosses it, how often, and what does that crossing cost in latency, money and failure modes? If the answer is "a great deal, constantly, for no independence benefit", the boundary is in the wrong place.

And the counter-example that keeps it honest: if one stage needed to scale independently, or used a GPU, or was owned by a different team, the distributed design would be correct despite the cost.

Common weak answers

Optimising the functions' runtime or memory. Concluding serverless is unsuitable for data processing generally.