About a month ago, an overseas client — let's call him Teddy — approached Snowpad with a high-demand use case: continuous high-bitrate video streaming that required massive concurrency, demanding upwards of 500 concurrent connections across our network.
- Client demand: 500 concurrent streams
- Current fleet ceiling: ~35 streams per node
- Result: severe bottleneck
Watching your own infrastructure stall when a client is actively testing your limits is one of the most frustrating experiences in backend engineering — especially when you're running Snowpad solo and there's no second pair of eyes to bounce ideas off. What made it worse was looking at the system metrics: node CPU usage and memory consumption were barely breaking 15%.
The hardware was not exhausted. The mobile carriers were not hard-throttling us. Something inside our software transport layer was choking the pipeline.
So I went heads-down: countless days of debugging, failed stress tests, and packet inspection, until I finally identified the root cause. The fix was a fundamental rewrite of the transport layer — one that unlocked a 3x concurrency multiplier per node.
Here is what went wrong, what I fixed, and how we unlocked a 3x concurrency multiplier per node.
The Hidden Killer: TCP Multiplexing Overhead
To route traffic securely from distributed mobile nodes back to our central gateways, our architecture relied on transport tunneling configured with single-stream TCP multiplexing.
In traditional networking theory, multiplexing seems ideal:
- It packages multiple logical streams into a single TCP connection.
- It minimises the overhead of frequent TCP handshakes.
- It keeps operating system socket management tidy.
In high-concurrency environments like video streaming and high-frequency web scraping, this theoretical advantage completely breaks down.
Because every logical request was packed into a single multiplexed TCP pipe, head-of-line blocking became the primary bottleneck. If a single packet was delayed or dropped across the cellular network, every other request in that multiplexed stream was forced to wait. On top of that, the constant framing and deframing of custom protocol headers inside the tunnel layer burned unnecessary CPU cycles and created packet-queuing delays.
We had built an internal software traffic jam.
The Breakthrough: Pre-Warmed Connection Pools
To fix this, I rewrote the core tunneling logic across the fleet.
I stripped out the multiplexing framing layer completely and replaced it with dedicated, pre-warmed connection pools (poolCount = 5).
Instead of forcing 50+ concurrent requests through a single framed stream, incoming connections are now distributed across independent, clean transport tunnels. If one connection hits a cellular delay, the rest of the pool continues routing traffic without missing a beat.
I immediately ran comprehensive hammer tests across the fleet to measure the impact:
The Benchmark Results
- A true 3x concurrency jump. Prior to this change, the nodes topped out at 30–40 connections on Jio and ~50 on Airtel. Post-upgrade, 6 out of 7 reachable nodes handled the full ramp to 100+ concurrent streams at a 100% success rate.
- Sub-second p95 latencies. On high-performance carriers like Jio, p95 latency hovered between 494ms and 567ms under peak saturation.
- Isolated carrier behaviour. Airtel nodes maintained a 100% delivery rate, though latency degraded past 30 concurrent streams (reaching ~3.3s p95). Because the tunneling layer is now clean, I could definitively prove this was cellular radio queueing rather than an internal software bug.
These results line up with our broader carrier benchmarks — see our Jio vs Airtel carrier comparison and our sticky proxy concurrency benchmark for the underlying data.
Concurrency vs. Bandwidth: The Technical Reality
When managing proxy infrastructure, it is essential to distinguish between connection concurrency — the total volume of parallel active sessions — and raw aggregate throughput, or bandwidth.
Our latest tunnel infrastructure upgrade at Snowpad.io was engineered specifically to maximise session concurrency rather than brute-force transfer speeds. Each mobile tunnel node is calibrated to maintain an aggregate throughput ceiling of 12 to 20 Mbps, which is purposely optimised to effortlessly sustain over 100 parallel streams per node.
For high-frequency automation workloads — structured web scraping, JSON REST API consumption, headless browser data extraction, multi-threaded portal scraping — this high-concurrency envelope provides extraordinary speed, stability, and high IP trust without wasting unnecessary bandwidth.
However, when dealing with single-stream multi-gigabyte raw file downloads, high-definition video streaming, or data-intensive pipelines, raw bandwidth becomes the main bottleneck that mobile proxy architectures simply cannot solve.
To address these heavy data requirements, Snowpad.io has partnered with Rawat Broadband to introduce high-speed on-demand residential proxies capable of delivering up to 200 Mbps. This strategic collaboration bridges the gap between high-trust IP routing and massive data throughput, allowing clients to run bandwidth-heavy operations smoothly alongside their lightweight scraping tasks.
Regional Expansion and Partnerships
In addition to our expanding core network, we have the technical capability to deploy custom on-demand proxy infrastructure tailored to specific regional locations across India, including dedicated residential and mobile pools in Gujarat, Bangalore, and other key markets.
We are actively open to small-scale regional partnerships as well as deeper collaborations with local ISP providers to expand our geographic coverage under custom network constraints.
Closing
Overall, this comprehensive infrastructure upgrade makes our backend capacity three times more robust, resulting in an end-user experience and execution speed that feels up to nine times faster across the board.
If you're running high-concurrency scraping or automation workloads on Indian mobile IPs and need more headroom per node, start a free Snowpad trial or talk to us about a custom regional pool.
