Ingest Fan-In
The shape of a system receiving many small messages from very many senders, where connection count rather than data volume is the primary constraint.
A web application has relatively few clients sending relatively large requests. An IoT ingest has the inverse: hundreds of thousands of devices each sending a few hundred bytes, frequently, over long-lived connections.
That inversion moves the bottleneck. Concurrent connection count, not throughput, is what sizes the front tier — each connection consumes memory and file descriptors whether or not it is carrying data. Per-message overhead dominates: a protocol header comparable in size to the payload doubles the bill, which is why constrained protocols exist. And authentication cost is paid per connection rather than amortised, so a fleet reconnecting simultaneously after a network event is a thundering herd against the identity path.
The design responses follow. A protocol-aware broker that holds connections cheaply sits in front. Devices reconnect with jittered exponential backoff, because synchronised reconnection is the most common self-inflicted outage in a large fleet. Messages are batched at the device or gateway where latency permits. Duplicates are expected — at-least-once is what unreliable links give — so the ingest path must be idempotent on a device-supplied identifier rather than assuming uniqueness.