Every software startup begins life in a sandbox. When we first started writing code for Audio Realm, the database ran on a local machine, the audio files were hosted on a local dev server, and testing was done by opening three tabs in the same browser window. Everything was simple, fast, and secure. But moving an application from a local sandbox to a production-ready, multi-tenant cloud infrastructure is where real-world software engineering begins. For an indie project, this transition presents a unique set of challenges.
When you allow users to upload their own audiobooks and podcasts to their personal storage libraries, you are handling their private media. You need to ensure that files are kept strictly confidential, while also delivering high-speed streaming to multiple synchronized listeners. Here is how we designed and scaled the architecture for Audio Realm.
The Architecture: Decoupled and Secure
We chose a decoupled microservices architecture to ensure scalability and ease of deployment. The frontend is built as a static application served globally via an edge CDN (Vite and Firebase Hosting). The backend services run inside containerized Cloud Run instances, which auto-scale dynamically based on incoming traffic. This keeps running costs low while giving us the power to support thousands of active rooms during peak hours.
The core storage engine is built on Google Cloud Storage (GCS) and Cloudflare R2, designed to protect user privacy while serving high-throughput media:
- Private-by-Default Buckets: All user-uploaded media files are stored in access-restricted buckets. There are no public URLs for user audio files.
- Secured Presigned URLs: When a room host plays a track from their library, the backend generates a time-limited, cryptographically signed URL for that specific file. These presigned URLs expire automatically after 2 hours, preventing them from being shared or leaked outside the active room.
- Decoupled Playback Metadata: The timeline, synchronized room clock, and listener details are managed by a lightweight, memory-efficient WebSocket server. The actual audio data flows directly from the cloud storage bucket to the user's browser, bypassing the room server entirely. This prevents the websocket server from becoming a bottleneck during heavy playback.
Overcoming the Cold Start Challenge
One of the biggest hurdles of using serverless containers (like Cloud Run) is "cold starts"—the delay when a container is spun up from scratch to handle a new request. For a voice and listening app where immediate response is critical, waiting 3 seconds for a server to boot is not acceptable.
We solved this by implementing a warm-standby pool and utilizing Node.js lightweight runtimes. The backend is written in TypeScript and compiled into a single, optimized CJS bundle using Esbuild. The resulting server bundle is under 1MB, allowing new server instances to initialize and begin accepting WebSocket connections in **under 150 milliseconds**.
Building for the Long Haul
Scaling as an indie platform is about making smart, efficient decisions. By leveraging serverless scaling and direct-to-browser media streaming, we created an infrastructure that is cheap to run at rest, yet scales dynamically to handle large crowds. Most importantly, it guarantees complete isolation of user media. As we continue to expand the platform's features, this solid foundation gives us the freedom to build with confidence.