Practice this topic in a realistic system design interview
Most real-time web features keep a server in the middle. Long polling, SSE, and WebSockets are good choices for notifications, chat, dashboards, and collaborative state. In those systems, messages usually pass through your application servers.
Video calls are different. Sending every audio and video packet through your servers adds latency and burns bandwidth.
WebRTC is a set of browser APIs and network protocols for sending audio, video, and data with very low delay. When the network allows it, WebRTC sends that traffic directly between the two users.
WebRTC is often called peer-to-peer, but that does not mean "no servers." Most users sit behind home routers, firewalls, mobile networks, or corporate proxies. A production WebRTC system still needs servers to set up calls, help users find a network path, relay traffic when direct paths fail, and scale group calls.
This chapter explains what WebRTC gives you, what your application must still build, how signaling, ICE, STUN, and TURN fit together, why group calls usually need media servers, and what to watch in production.