Why We Ditched Cloud Storage: Building a Zero-Server Media & P2P Engine with WebRTC & WASM

When building a high-traffic media and file utility site, the traditional architecture looks like this:

1. User uploads a 2GB video or file to your server (AWS S3 or Cloudflare R2).
2. Backend workers process or hold the file.
3. User or recipient downloads it back.

The catch? Bandwidth egress fees and disk storage costs can bankrupt an indie project overnight. Not to mention the severe privacy concerns of storing sensitive user media on cloud servers.

To solve this, we took a radical approach when building PullDL and its cross-device transfer system PullDrop: Zero server storage. Everything runs P2P via WebRTC or client-side in the browser via WebAssembly.

Here is the architectural breakdown and key engineering lessons we learned along the way.

1. Cross-Device P2P File Transfer with WebRTC (The AirDrop Alternative)

Apple’s AirDrop is amazing, but it locks out Android, Windows, and Linux. Most web-based alternatives (like Snapdrop or early file portals) frequently suffer from connection drops when transferring large multi-gigabyte files.

In PullDrop, we engineered a resilient WebRTC DataChannel pipeline:

• 6-Digit Ephemeral Signaling: Instead of heavy WebSocket room orchestration, we use short-lived 6-digit handshake keys backed by in-memory Redis keys with an aggressive 10-minute TTL.
• Adaptive 16KB Chunks: Mobile Safari and Android Chrome aggressively throttle or kill WebRTC buffers if you send chunks larger than 64KB. By throttling transmission to adaptive 16KB binary frames, we achieved zero-interruption transfers even for 4K video libraries.
• Pure P2P Stream Saving: As packets arrive, chunks are written directly into local browser blobs, avoiding browser memory heap overflows.

If you want to see how this performs between Apple and Windows devices, you can test it directly on AirDrop for Windows.

2. Pushing Media Processing to the Edge with WebAssembly (WASM)

Many converters and audio tools (e.g., vocal isolation, pitch shifting, MOV-to-MP4 transcoding) are notoriously CPU-heavy. Running ffmpeg or DSP algorithms on a VPS cluster would require scaling dozens of GPU/CPU servers.

Instead, we offloaded 90% of processing directly to the client's CPU via WebAssembly (WASM) and the Web Audio API:

javascript
// Example: Processing audio offline via Web Audio Context in client memory
const audioCtx = new (window.AudioContext || window.webkitAudioContext)();
const source = audioCtx.createBufferSource();
const biquadFilter = audioCtx.createBiquadFilter();

biquadFilter.type = "lowshelf";
biquadFilter.frequency.value = 200;
biquadFilter.gain.value = 15; // In-browser sub-bass processing

source.connect(biquadFilter);
biquadFilter.connect(audioCtx.destination);