Live audio rooms for political networks, first release in 16 weeks

The situation

Political conversation in Andhra Pradesh runs through a hierarchy: MPs, MLAs, constituency leaders, badge-holding party members, and the citizens they represent. Voter IQ's founder wanted that whole structure talking in one app. Leaders would host live audio rooms. Members would follow the right leaders. Citizens would listen, comment, and vote in polls, without getting leader-level access.

WhatsApp groups and public social feeds couldn't do that. They don't know who is an MLA, which constituency someone belongs to, or where a local complaint should go next.

There was also a hard deadline. Elections were coming. If the first phase missed them, the app would have nothing to be used for until the next cycle.

The founder picked RaftLabs because of our real-time voice work for PSi. We shipped the first iOS, Android, and admin release in 16 weeks. Then the founder asked whether it could handle 200,000 people at once. We ran load tests before giving any number, and the answer is on this page.

What discovery changed

• The hierarchy was the product, not a setting

  We expected roles and permissions to be one module among many. It turned out every feature depended on them: who sees which room, whose feed shows which issue, where a complaint goes next. The founder held that domain knowledge, and our PM spent several rounds getting it out of his head and onto paper before the backend engineer designed a single table.

  The data model then went through more iterations. Once the founder used a working build, he saw gaps the whiteboard version had hidden. We rebuilt parts of the structure to fit what he'd learned.

• The admin panel had to act for users, not just manage them

  The plan was a minimal super admin panel. Mid-build, the founder explained that many end users wouldn't do the key actions themselves. Someone would do it on their behalf. That turned the admin panel into a second product, with its own flows for acting as a user.

  Our PM's own takeaway: agree visually on the admin panel early, and ask how it will really be used, not just what it should contain.

• We pushed back on deleting constituencies

  The founder asked for a feature to delete a constituency. On paper it's one button. In the data model, almost everything hangs off a constituency: members, leaders, groups, issues, and escalation paths. Deleting one safely needs careful planning for every record attached to it.

  We moved it to a later phase rather than rush it into the election release. A half-planned delete in a hierarchy like this breaks things silently.

The engineering problems worth reporting

• Mapping a democratic hierarchy into a data model

  Challenge. The product needed to place every user in the right party and constituency, give them the right powers, and build a feed of upcoming sessions and issues based on their role and geography.

  Approach. We kept network membership, following, discussion roles, and admin authority as separate concepts. The shortcut was one "role" field. That would have let a follow relationship quietly grant organisational access, and it would have made counts disagree across screens.

  Result. Four user groups (mobile admins, badge holders, non-badge-holder citizens, and web super or sub-admins) each got distinct actions. When deleted users were still showing in network totals, we fixed the counting rule in the backend, so mobile and admin views read one definition instead of disagreeing.

• Issues that climb the hierarchy on their own

  Challenge. A constituency leader raises an issue. It should reach a specific higher-level leader. If that leader doesn't act in time, it shouldn't just sit there.

  Approach. We built a routing and escalation workflow. Each issue is assigned to the next leader up the chain, with a time limit. If it isn't actioned in that window, the system moves it up another level automatically.

  Result. Local problems have a defined path from constituency level toward the MLA and MP, and silence at one level doesn't end the issue.

• A 10,000-user audio target, and a 200,000-user question

  Challenge. The architecture was designed for up to 10,000 people in one audio session. Then the founder asked whether it could reach 200,000.

  Approach. We didn't answer with a number from a slide. We tested two layers separately. Artillery drove HTTP application traffic, and k6 opened WebSocket connections. Agora handled the audio itself. The app controlled who could host, speak, listen, comment, and vote.

  Result. At 1,000 concurrent HTTP users, all 2,000 requests succeeded at 347 ms p95. At 5,000, only 7,824 of 10,000 succeeded and p95 rose to about 3.1 seconds. That's degradation, not a pass. WebSockets reached about 7,854 simultaneous connections before latency climbed. All of this ran on one AWS EC2 m5a.large, at about $38 a month at the time.

• An audio join failure that only showed up in production

  Challenge. Users hit Agora's CAN_NOT_GET_GATEWAY_SERVER error in production, reported with an invalid-token message.

  Approach. We compared the generated token with the join parameters. The app was passing a UUID string where the SDK flow we'd implemented expected a numeric UID.

  Result. Switching to a numeric UID fixed the failure. The general lesson is to check the SDK's contract, not just the token, whenever a join fails.

1. Live audio rooms with political roles built in

   Leaders host rooms, invite co-hosts, and bring speakers up. Citizens listen, comment, and vote in live polls. Agora carries the audio. The app decides who can do what, based on each person's place in the network.

   

2. One React Native codebase for iOS and Android

   With an election date fixed, two native codebases would have doubled the work. React Native let the team share most of the product across both stores and keep platform-specific code where iOS and Android behaved differently. Both Google Play and the App Store list live discussions, issue-based polls, and geographic groups.

   

3. Constituency groups and issue escalation

   Users land in groups tied to their constituency. Their feed shows the sessions and issues that fit their role and location. Issues raised by constituency leaders go to a named higher-level leader and escalate automatically if nobody acts.

   

4. A super admin panel that can act on a user's behalf

   Super and sub-admins manage networks, members, and permissions from the web. Because many users wouldn't do key actions themselves, the panel also lets admins carry those actions out for them.

   

How it runs

React Native

An election date left no room for two native builds. One shared codebase shipped iOS and Android in 16 weeks, with platform-specific code where behaviour differed.

Agora

Carried the live audio, so the team built political roles and permissions instead of a media server. The app still owned who could host, speak, and listen.

AWS

One EC2 instance ran the tested setup at about $38 a month, with Lambda for background jobs. That kept costs tied to real demand, not a hypothetical peak.

Firebase

Handled push notifications for upcoming sessions and mobile analytics, outside the main backend.