In my real-time object detection dashboard, a browser sends camera frames to a server, the server runs a detector and sends back boxes. A camera produces frames faster than a detector can process them.
What a queue does here
The ordinary answer is a queue: keep every frame and process them in order. For live video that is the wrong answer. If frames arrive faster than they are finished, the queue only grows, and the picture on screen falls further behind the camera with every second. Nothing has failed, and the dashboard is showing the past.
For a live view, an old frame is worth very little. What matters is what the camera sees now.
One frame, one acknowledgement
So the client sends one frame and waits for the server to acknowledge it before sending another. While it waits, newer frames replace older ones. When the acknowledgement comes, the client sends the most recent frame it has.
There is never more than one frame in flight for a connection. Delay is bounded by how long one inference takes, not by how long the session has been running.
Limits on the server
The server also refuses to be overwhelmed. It caps the number of connections, the target frame rate and the size of a frame, so one large or aggressive client cannot take all the capacity.
Being honest about it on screen
Dropping frames is a decision the operator should be able to see. The dashboard reports latency and throughput alongside the detections, so it is clear when inference is the constraint instead of implying the stream is perfectly live.
When this would be wrong
If every frame mattered, for example when recording evidence, dropping would be the wrong design and a durable queue would be right. Backpressure is a choice about what the consumer needs. Here it needs the present.