advanced 2 min answer

An IoT ingestion pipeline is falling behind. The devices cannot be slowed down. What are your options?

backpressureedgeoverload
Show the full answer Hide the answer

What the interviewer is testing

Whether you can design flow control at a boundary where the producer cannot be told to stop — which is the interesting case.

Why standard backpressure does not apply

Backpressure works by a consumer signalling a producer to slow down. A device fleet, a payment network, or a partner feed cannot be slowed: the devices will keep transmitting, and if the ingest endpoint rejects them they will retry, amplifying the load.

So the choice is not whether to shed, but what to shed and where.

The options

Buffer at the edge. Devices or gateways hold data locally and transmit when accepted. This is the best option where the hardware supports it, because it converts a loss into a delay. It needs an explicit policy for what happens when the local buffer fills — and that policy must be designed, not discovered.

Aggregate at the gateway. Send a minute's statistics rather than sixty readings. Reduces volume by an order of magnitude without losing the shape, and is usually the highest-value change.

Filter at the source. Report on change beyond a threshold rather than on a timer. For stable sensors this eliminates the large majority of messages.

Shed by priority at ingest. Accept alarms, events and state changes; drop routine telemetry. Requires the message to carry a priority the ingest layer can read cheaply, without deserialising the whole payload.

Sample. Accept a defined fraction of routine telemetry, keeping statistical validity while reducing volume.

Spill to cheap storage. Write raw messages to object storage at ingest and process asynchronously, converting a throughput problem into a latency one. Good when the data is needed but not urgently.

The design principle

Decide the degradation policy in advance and make it explicit. Systems that have not chosen discover their policy at 3 AM, and the default — drop whatever arrives when the buffer is full — is the one that loses the anomaly you most needed.

What a strong answer adds

The exception that must survive every mechanism: anomalies and alarms need full resolution and immediate transmission. A system that downsamples the minute in which a machine failed has optimised away the only data anyone wanted, so filtering must be conditional rather than uniform.

Common weak answers

Scaling ingest capacity indefinitely, which is expensive and does not address a fleet that grows. Rejecting messages without considering retry amplification.