URL: https://champanzee.tech GITHUB: https://github.com/rbous/champanzee

How We Built It

We designed and implemented Champanzee as a horizontally scalable, Kahoot-like survey platform where players progress asynchronously (not synchronized per question). Each participant advances at their own pace while still competing on a shared leaderboard.

At a high level, the system is built around Survey templates, Live Rooms, Per-player queues, and an AI-powered evaluation and follow-up engine.


Core Architecture

To support real-time interaction, AI evaluation, and scalability, we used a hybrid architecture:

  • Redis (Live State & Performance Layer)
    Redis acts as the source of truth for all live data:
    • Room state and status
    • Player sessions and per-player question queues
    • Leaderboards (using sorted sets)
    • Draft answers, attempts, and follow-up pools

This allows constant-time updates without expensive database queries and makes horizontal scaling (multi-instance servers, Kubernetes) feasible.

  • MongoDB (Persistence Layer)
    MongoDB stores long-lived data:
    • Survey templates
    • Full player responses
    • AI evaluations and extracted signals
    • Post-room analytics and reports

Its NoSQL structure fits our deeply nested and evolving data models (questions, analytics, AI outputs).

  • WebSockets (Real-Time Communication)
    We used Go with the Gorilla WebSocket library for high concurrency and low latency.
    Hosts receive real-time leaderboard and analytics updates, while players get instant feedback without polling.

Survey → Room → Player Flow

Host Flow

  1. The host creates a Survey template (stored in MongoDB) containing base questions and scoring rules.
  2. A Room is created from the survey:
    • Live room state is initialized in Redis
    • A room code is generated for players
  3. The host uploads contextual material (slides or descriptions).
    • AI summarizes this into a scope anchor stored in Redis.
  4. AI generates follow-up question pools for each base question.
    • The host can review and approve them.
  5. The room status switches to ACTIVE, and the host receives live updates via WebSockets.

Player Flow (Async Pace)

  1. A player joins using the room code and receives a session token.
  2. Each player gets a personal question queue initialized as:

( Q = [Q_1, Q_2, Q_3, \dots] )

  1. Draft answers are saved locally and optionally in Redis to avoid retyping.
  2. When an answer is submitted:
    • The response is stored
    • AI evaluates the answer
    • Scores, analytics, and leaderboards are updated
  3. If needed, a follow-up question is inserted into the player’s queue.
  4. The player continues until their queue is empty.

Question Types & AI Evaluation

We support multiple question types with different behaviors:

  • Essay Questions

    • Free-text answers
    • AI evaluates quality and determines if the answer is satisfactory
    • Can gate progression
    • Can trigger follow-ups
    • Higher point value
  • Degree / Rating Questions

    • Numeric answers (e.g. 1–5 or sliders)
    • Never gate progression
    • Can trigger follow-ups based on thresholds or outliers
    • Strong input for analytics

For essay questions, AI extracts structured signals such as:

  • Themes
  • Missing details
  • Clarity and specificity
  • Sentiment
  • One-sentence summaries

These signals are used for both scoring and analytics.


Scoring & Leaderboards

All scoring is server-owned to prevent manipulation.

For essay questions, points are computed as:

$$ \text{points} = \min\left( \text{qualityScore} \times \text{pointsMax}, \ \text{pointsMax} \right) $$

Degree questions award fixed or scaled participation points.

Leaderboards are maintained in Redis using sorted sets, allowing instant ranking updates without costly re-sorting.


Follow-Up System

Follow-ups are a core feature of Champanzee and include:

  • AI-generated question pools (host-approved)
  • On-demand personalized probes
  • Clarification questions (missing details)
  • Deepening questions (examples, trade-offs)
  • Challenge questions (inconsistencies)
  • Comparison questions (forced choices)

If a player skips a question, all remaining follow-ups linked to that question are automatically closed, while drafts and previous answers are preserved.


Analytics at Multiple Levels

The system collects insight at four levels:

  • Per-answer: quality, satisfaction, extracted signals
  • Per-player: consistency, effort, progression
  • Per-question: distributions, misunderstandings, follow-up effectiveness
  • Per-room: themes, contrasts, friction points, outliers

Real-time analytics live in Redis, while post-room summaries and exports are stored in MongoDB.


This architecture allows companies to extract deep, structured insights while players experience a smooth, competitive, and engaging survey workflow.

Built With

Share this project:

Updates