Design a Walkie-Talkie Style Push-to-Talk App

Problem statement

Design a walkie-talkie style push-to-talk (PTT) platform. A user presses and holds a button to speak, releases it to listen, and their audio is delivered in near real time to every member of a channel. Exactly one user holds the floor at a time. The platform must manage channels and membership, arbitrate who may speak, stream low-bitrate audio to potentially thousands of listeners, track presence, buffer audio for users who join a transmission late, and optionally retain short voice logs.

This is not a WebRTC conference call with the camera off. A full-duplex mixer assumes everyone can talk simultaneously and pays the cost of N uplinks plus echo cancellation. A walkie-talkie is half-duplex by design: one uplink, N downlinks, and a coordination problem in the middle called floor control. The floor arbiter is the heart of the system. It must grant the channel to one speaker, deny or queue everyone else, detect when the speaker releases the button or loses connectivity, and hand the floor to the next requester with fairness and priority semantics. If the arbiter is wrong, two people talk over each other and the walkie-talkie illusion breaks instantly.

Why the problem is distinctive

A chat system can tolerate a message arriving two seconds late. A live voice transmission cannot: mouth-to-ear latency above roughly 400 ms feels like a broken radio, and above 800 ms conversation collapses into people talking over each other. At the same time, mobile PTT clients live on hostile networks: cellular handoffs, NATs, tunnel entrances, elevators, and basements. The design therefore separates three concerns that a naive design fuses together: signaling (who has the floor), media (the audio bytes), and membership (who should receive them). Signaling must be strongly ordered per channel. Media must be fast and loss-tolerant. Membership must be consistent but changes slowly.

PTT is operationally real. Zello reports a very large consumer and work-crew install base and became notable during hurricane relief because it operates over low-bandwidth data links when circuit-switched voice is congested. Motorola Solutions sells WAVE PTX and participates in the 3GPP Mission Critical PTT (MCPTT) standards, which formalize floor control, preemption, and emergency calls over LTE. Microsoft shipped a walkie-talkie feature in Teams for frontline workers, explicitly choosing half-duplex to save battery compared with full-duplex calls. These are public signals that the category works; every uncited number in this answer is an explicit design assumption.

The four architectural planes

Signaling plane: WebSocket or MQTT gateway, per-channel floor arbiter, grant/deny/revoke messages, presence heartbeats.
Media plane: UDP/RTP ingest from the speaker, Opus payload handling, per-channel replication fanout (SFU-style), jitter and catch-up buffering.
Membership and presence plane: channel store, join/leave, online/offline state, listener counts, mute and moderation.
Retention and evidence plane: 30-second live replay ring per active transmission, optional voice notes, abuse reports, audit.

A strong answer keeps these planes separate. Presence fan-out must never block a floor grant. A replay upload must never delay live audio. And the floor arbiter must remain correct even when the media path is degraded.

Key Highlights

•The floor arbiter is a per-channel single writer; floor state is the only strongly ordered signaling state.
•One uplink, N downlinks: media egress is fanout-dominated, unlike peer-to-peer calls.
•Mouth-to-ear latency targets under 300 ms p50 make media path design a first-class problem.
•Zello, Motorola WAVE PTX / 3GPP MCPTT, and Teams walkie-talkie prove the category in public.
•Separate signaling, media, membership, and retention planes so each degrades independently.