C24 クラブの構築: 報酬駆動型ビデオチャットプラットフォームのアーキテクチャ

ランダムビデオチャットは外見だけシンプルに見えます！ボタンを押し、素知られずの人と会う。しかし、ライブ報酬経済、性認知的マッチメイキング、AI モデレーション、そしてグローバルな同時接続ユーザー数を加えると、エンジニアリングの課題は単純な Omegle クローンとは全く異なります。 本稿では、ユーザーが対話するたびに実在し換金可能な報酬を獲得できるブラウザベースのビデオチャットプラットフォーム「C24 クラブ」を支えるハイレベルなアーキテクチャを解説します。 C24 クラブは、対話するたびに報酬分（ギフトカード、デザイナー製品、PayPal 現金に交換可能な時間）を獲得できるという1 つの大きな特徴を持ったブラウザベースのランダムビデオチャットプラットフォームです。 プラットフォームは以下の4 つの柱で構築されています： ⚡ 定期呼び出しウィンドウ中のサブ秒レベルマッチメイキング C24 クラブはサーバーレスファースト、エッジネイティブなアーキテクチャを採用しています。長寿命な Node サーバーを実行する代わりに、ほぼすべてのバックエンド操作はユーザーに近く展開された Supabase エッジ関数（Deno）として実行されています。 サーバーレスエッジコンピューティングによるインフラ維持コストの削減 データベースが唯一の真実のソース：Postgres + RLS カスタム認証層の代替 WebSockets を使用したポーリングによるマッチメイキングの信頼性（より詳細については後で記載） ビデオやオーディオを触らぬピア対ピア（P2P）メディアバックエンド 価値変化操作（報酬獲得、ギフト、現金引き出しなど）の任意の操作に対して原子データベース関数 1️⃣ フロントエンド：React + Vite で最適化された高速化 ユーザー向けアプリ全体はビデオ呼び出しのホットパス（重要ルーター）に対して最適化されたシングルページ React アプリです。 React 18 + Vite 5 + TypeScript 5 でデベロッパー環境では即時的 HMR、プロダクションでは小さなバニラバンドル Tailwind CSS + shadcn/ui の意味論設計トークン（HSL ベース）が、ライト/ダークモード全体で一貫したテーマを駆動 TanStack Query キャッシングレイヤーが、データベースを叩くことなく、Discover フード、リーダーボード、および分数残高を最新の状態に保つ React Router が Reward Store、Profile、Discover（ Reward Store、Profile、Discover（重要 UX 要件：ページを離れると呼び出しが切断される））へのナビゲーションを維持してアクティブな WebRTC 接続を維持 私たちは可能な限りブラウザ内で作業を行い、プライバシーを保護しサーバーコストを削減します： NSFWJS はリモートビデオフレーム上でローカルに動作し、0.75 の不名誉閾値を使用してポリシー違反をフラグ付けします。ビデオがピア接続を離れることはありません。 ブラックスクリーン検出はローカルに動作し、ユーザーが報酬システムをゲームにしないように防止します。 プリブレアシャードは、すべてのマッチの最初の 1 セカンンドでパートナーのフールを隠し、フラッシュ露出を防止します。 2️⃣ バックエンド：軽量エッジシグナリング 私たちのバックエンドは単一のビデオフレームにも触れません。その仕事は調整、永続化、そしてお金です。 Supabase エッジ関数（Deno） 私たちは、ビデオ呼び出しマッチ（マッチメイキングの脳）からギフト分（Stripe バックアップされたギフト）から NSFW バン（自動執行）まで、すべてを扱うエッジ関数約 70 機能があります。各関数： 冷たい起動が 100 ミリ秒未満で完了 必要とする秘密のみを読み取ります Supabase JWT を認証します ユーザー向けホットパスのために 1 セカンンド未満で返ります PostgreSQL + 行レベルセキュリティ（RLS） Postgres が唯一の真実のソースです。RLS ポリシーがデータベースレイヤーでユーザーごとのアクセスを強制するため、フロントエンドはカスタム API サーバーの前面なしで直接クエリを実行できます。 センシティブな操作（分数の増加、報酬の主張、ウェーガルの処理など）は、原子 SQL 関数（atomic_increment_minutes、redeem_reward_atomic）にラップされ、競合状態と二重発行を防ぎます。 ストレージと認証 プロフィールの自画像、ギフトカード画像、チャレンジプローフスクリーンショットのための Supabase ストレージ（すべて RLS の背後にある） Supabase Auth Google、Apple、およびメール/パスワードの認証 — アプリ全体で共有される JWT セッション 3️⃣ リアルタイムレイヤー：ポーリングよりも WebSockets を選ぶ理由 これはスタック上で最も反直観的な決定です。私たちは元来、Supabase Realtime（WebSockets）上でマッチメイキングを構築しましたが、競合状態で信頼性問題（サイレント切断、見逃されたイベント、ゴーストマッチ）に遭遇しました。 4️⃣ ビデオ：WebRTC を使用した純粋な P2P 2 ユーザーがマッチされたら、バックエンドは完全に背後に退きます。 WebRTC オファー/アンサーが単一のエッジ関数（videocall-match）を通じて交換されます ICE キャンディデートがゆっくりと透過します

Random video chat looks simple from the outside! click a button, meet a stranger. But the moment you add a live rewards economy, gender-aware matchmaking, AI moderation, and a global concurrent user base**, the engineering challenge becomes very different from a basic Omegle clone. In this post, we walk through the high-level architecture powering C24 Club a browser-based video chat platform where users earn real, redeemable rewards for every minute they spend connecting with strangers. C24 Club is a browser-based random video chat platform with one major twist: every minute you talk earns reward minutes that can be redeemed for gift cards, designer products, and PayPal cash. The platform is built around four pillars: ⚡ Sub-second matchmaking during scheduled call windows C24 Club follows a serverless-first, edge-native architecture. Instead of running long-lived Node servers, almost every backend operation is a Supabase Edge Function (Deno) deployed close to the user. Serverless edge compute no idle infrastructure costs Database as the source of truth Postgres + RLS replaces a custom auth layer Polling over WebSockets for matchmaking reliability (more on this below) Peer-to-Peer (P2P) media backend never touches video or audio Atomic database functions for any value-changing operation (earnings, gifts, cash-out) 1️⃣ Frontend: React + Vite, Built for Speed The entire user-facing app is a single-page React application optimized for the video call hot path. React 18 + Vite 5 + TypeScript 5 instant HMR in dev, tiny production bundles Tailwind CSS + shadcn/ui semantic design tokens (HSL-based) drive consistent theming across light/dark TanStack Query caching layer that keeps Discover feeds, leaderboards, and minute balances fresh without hammering the database React Router preserves the active WebRTC connection across navigation to Reward Store, Profile, and Discover (a critical UX requirement — leaving the page would drop the call) We do as much work in the browser as possible to protect privacy and reduce server cost: NSFWJS runs locally on remote video frames with a 0.75 nudity threshold to flag policy violations no video ever leaves the peer connection. Black-screen detection runs locally to prevent users from gaming the rewards system. Pre-blur shield hides the partner feed for the first second of every match, preventing flash exposures. 2️⃣ Backend: Lightweight Edge Signaling Our backend never touches a single video frame. Its job is coordination, persistence, and money. Supabase Edge Functions (Deno) We have ~70 edge functions handling everything from videocall-match (the matchmaking brain) to gift-minutes (Stripe-backed gifting) to nsfw-ban (automatic enforcement). Each function: Boots cold in <100 ms Reads only the secrets it needs Authenticates via Supabase JWT Returns in well under 1 second for the user-facing hot paths. PostgreSQL + Row-Level Security Postgres is the single source of truth. RLS policies enforce per-user access at the database layer, so the frontend can query directly without a custom API server in front. Sensitive operations incrementing minutes, claiming rewards, processing wagers are wrapped in atomic SQL functions (atomic_increment_minutes, redeem_reward_atomic) to prevent race conditions and double-spends. Storage & Auth Supabase Storage for profile selfies, gift card images, and challenge proof screenshots (all behind RLS) Supabase Auth with Google, Apple, and email/password — JWT sessions shared across the app 3️⃣ Real-Time Layer: Why We Chose Polling Over WebSockets This is the most counter-intuitive decision in our stack. We originally built matchmaking on Supabase Realtime (WebSockets), but at concurrency we hit reliability issues silent disconnects, missed events, ghost matches. 4️⃣ Video: Pure P2P with WebRTC Once two users are matched, the backend steps out of the way entirely. WebRTC offer/answer exchanged through a single Edge Function (videocall-match) ICE candidates trickled through the same channel Mandatory DTLS-SRTP encryption neither C24 Club nor any ISP can decrypt the stream Specific role enforcement: in random match the queue-joiner is always Offerer, the queue-finder is always Answerer (this single rule eliminated the vast majority of our connection failures) Here is what actually happens when a user clicks START: 1️⃣ Pre-flight (client) Selfie gate verifies the user has uploaded a Discover photo Camera permission is requested Local NSFW model and black-screen detector spin up 2️⃣ Queue join (edge) videocall-match inserts the user into the matchmaking queue with their gender and preferences Atomic DB function returns the partner row if a complementary peer is already waiting 3️⃣ Signaling (edge) Both clients receive each other's user IDs Offerer creates SDP offer → POSTed to Edge Function → delivered to Answerer via short-poll Answer + ICE candidates flow back through the same channel 4️⃣ P2P established WebRTC connection upgrades to direct browser-to-browser Backend has zero involvement in audio/video from this point Local moderation models begin scanning the remote stream 5️⃣ Earning loop Every full minute, client calls atomic_increment_minutes RPC Server-side function validates session integrity and awards minutes (with female bonus rates, VIP multipliers, Power Hour boosts, and freeze-state checks all applied atomically) 6️⃣ Disconnect & re-queue User clicks NEXT → P2P torn down → user re-enters queue in <500 ms Skip-penalty rule deducts 2 minutes if a non-VIP user skips inside 5 seconds (prevents farming). This is the part most random-chat clones don't have, and it's where the architecture gets interesting. Calling minutes vs. gifted minutes decoupled balances so receiving a gift can't be cashed out without earning your own minutes too Gift checkout via Stripe opens in a new tab so the live call stays connected Atomic redemption redeem_reward_atomic deducts minutes and creates the redemption row in a single transaction; out-of-stock items trigger automatic refunds Anchor program female users earn cash payouts on top of minutes, settled via PayPal through anchor-earning and cashout-minutes Lucky Spin & Wage micro-games funded by a configurable daily cap, with prize weighting handled by a Postgres function for verifiable fairness. Running serverless can get expensive fast if you're not careful. Two architectural choices keep our cloud bill flat as we grow: Polling intervals are tuned per surface, not global DM badges every 10 s is fine; matchmaking needs 1 s Edge Functions for hot writes only read-heavy queries (Discover feed, leaderboard) hit Postgres directly with RLS, bypassing the function layer entirely No video storage. Ever. Streams are P2P-encrypted; we couldn't store them if we tried Client-side moderation NSFWJS runs in the user's browser, only flags (not frames) reach the server IP-based ban enforcement at the database level bans take effect on the next request CSAE compliance dedicated reporting flow, automatic underage ban with appeal path C24 Club's architecture is the product of a deliberate trade-off: boring, reliable infrastructure for the parts that matter (money, matchmaking, moderation) combined with bleeding-edge browser tech for the parts users feel (P2P video, instant matching, on-device AI). If you're building a real-time platform with money attached gifts, payouts, in-app economies the lessons we'd repeat are: Use atomic database functions for every value-changing path Pick polling over realtime sockets when reliability beats latency Never put your backend in the media path Run moderation on the client and trust the database, not the network 👉 Try the platform: c24club 💬 Questions about the stack? Drop them in the comments we love nerding out about edge-native architecture.