Under the hood
You don't need any of this to use VinglishTalk — but if you're curious how a live-audio app runs fast, cheap, and close to home, here's the shape of it. The whole thing is built to be run by one person, with predictable bills and data that stays in the country.
The two halves
Svelte 5 + SvelteKit
The interface you see — the lobby, rooms, classes, profiles — is a modern Svelte app, rendered on the server for a fast first paint and a clean mobile layer.
Elixir on the BEAM
Everything live — who's in a room, who's available in the Waiting Hall, the queue, the chat, the signaling — runs on a Phoenix server built for millions of tiny concurrent conversations.
The real-time backend is the interesting choice. It runs on the BEAM, the virtual machine behind Elixir and Erlang, which was designed for exactly this: vast numbers of cheap, isolated, always-on connections. Each person in a room costs about two kilobytes of memory, and message round-trips stay flat whether ten people are online or ten thousand. If one room crashes, the supervisor restarts just that room — the rest of the site never notices.
How the audio moves
The voice layer is WebRTC, and it's shaped differently for each format so that nobody's connection ever does more work than it has to:
| Format | How the audio flows |
|---|---|
| Normal room | The ≤3 speakers talk to each other directly (a small full-duplex mesh). Their mix is forwarded one-way to every listener through an audio server, so a speaker's upload stays constant no matter how big the crowd gets. |
| Audio Chat room | Voice is a direct, private link between the Sparker and the Echoer while they draft. What reaches the room is the finished card. |
| Live Class | Both speakers (teacher + current student) and every viewer connect through the same audio server. On Next, the server moves the mic from one student to the next. |
That audio server — the part that forwards each speaker's voice to a crowd — runs inside the same process as everything else, rather than as a separate piece of infrastructure. One server to deploy, microsecond-fast hand-offs, and automatic cleanup when a room ends.
What we keep, and what we don't
Live rooms are ephemeral. Their audio is written to disk only while the room is running and deleted the instant it ends — there's no archive of your stumbles and no replay. The one thing kept long-term is your three My Thinkings clips, highly compressed. And there is no AI transcription anywhere in the loop: when a conversation gets summarized, a human does it, on purpose. (Read why.)
The rest of the stack
- Database — PostgreSQL, holding accounts, room metadata, the social graph, and the economy.
- Accounts — sign in with Google or a password.
- Payments — a self-built bank-transfer QR flow, confirmed automatically by a webhook. No third-party checkout. (See Credits.)
- Hosting — a single self-managed server in Vietnam, so latency is low for the people we built it for and data stays close to home.
Ephemeral rooms, tiny storage, one server, no AI bills — every one of these is a deliberate boundary that keeps VinglishTalk cheap to run and simple to trust. The philosophy page explains why limits like these are features, not compromises.