Queue depth caps written for interactive traffic drop every large extract the moment human-driven jobs spike.
Most API gateways ship with defaults tuned to browser sessions and mobile calls. Those same limits sit in front of the nightly bulk pulls that populate model training sets.
When depth is exceeded the messages are rejected or aged out without retry logic that respects data freshness windows. Operations teams see green dashboards because the failure sits one hop downstream.
Procurement rarely budgets for separate high-throughput queues or dedicated integration workers. The assumption remains that one shared bus can carry both chatty UIs and heavy ETL without contention.
Vendors count throughput at the point of handoff rather than at the point of successful consumption. A queue that accepts a million messages but loses half overnight still meets the SLA.
Teams that notice the gap usually add ad-hoc scripts to re-queue dropped payloads. These scripts accumulate technical debt and create new failure modes when schema versions drift between runs.
Fixing the problem requires explicit queue sizing tied to measured extract volumes, not to peak human concurrency. It also demands monitoring that tracks end-to-end latency rather than per-hop acceptance rates.
Until that changes the cheapest integration wins on paper and the AI layer inherits incomplete data every single night.