AI Video Chat Application

Problem

Real-time video needs a transport that avoids routing media through a central server (for latency and cost), while still needing a backend for signaling, session authentication, and endpoint authorization — the classic WebRTC tradeoff between peer-to-peer media and a trusted control plane.

Architecture

FastAPI handles signaling and session management; WebRTC handles the actual peer-to-peer encrypted media stream once a session is authenticated. SQLAlchemy persists session/user state so authenticated endpoints can validate who's allowed into a given call.

Key decisions

• —FastAPI chosen for the signaling layer — async support matters here since signaling is I/O-bound (waiting on peer handshakes, not CPU-bound work).
• —Session management kept explicit and authenticated at the API layer, rather than trusting client-supplied peer IDs, since WebRTC's peer-to-peer nature means the backend is the only real chokepoint for access control.
• —Encryption relies on WebRTC's built-in transport security (DTLS-SRTP) rather than a custom scheme — no reason to reinvent transport encryption.