Case Studies/Video & Conferencing

Google Meet

WebRTC-powered video conferencing deeply integrated with Google Workspace

videowebrtcconferencingreal-timegoogleSFU

Case study boundary

Use this as a learning model.

This page explains architectural patterns and constraints inspired by Google Meet. It should not be read as the exact private production architecture or as a one-size-fits-all recommendation.

Evidence

Public info + inference

Learn first

Concepts behind this architecture

Overview

Google Meet is a video conferencing service built on open web standards (WebRTC) and tightly integrated with Google Workspace (Calendar, Gmail, Docs). It supports meetings of up to 1,000 participants with live streaming to 100,000 viewers. Meet’s architecture leverages Google’s global network backbone for low-latency media transport, server-side media processing for adaptive quality, and a progressive web approach that requires no client installation. Its design prioritizes reliability, accessibility, and seamless integration over protocol-level customization.

Scale

300M+

Daily meeting participants

1,000

Max participants per meeting

100,000

Live stream viewers

200+

Global PoPs

Requirements

Functional

  • Video and audio conferencing with screen sharing
  • Calendar integration with one-click join
  • Live captions and meeting transcription
  • Breakout rooms and polls
  • Recording to Google Drive
  • Live streaming to large audiences
  • Background blur and virtual backgrounds

Non-Functional

  • Low latency media delivery (<150ms glass-to-glass)
  • Adaptive quality based on network conditions
  • Browser-native — no plugin or app required
  • End-to-end encryption for small meetings
  • Global availability via Google edge network
  • Graceful degradation on poor networks

High-Level Architecture

Loading diagram...
Google Meet — High-level system architecture

Key Components

Signaling Service

Handles session setup, participant join/leave, and ICE candidate exchange using Google’s proprietary signaling protocol over HTTPS. Coordinates with Calendar and Workspace for meeting scheduling and authentication.

OASIS Media Router

Google’s custom media relay infrastructure deployed at edge PoPs worldwide. Routes encrypted media streams between participants using the shortest network path. Operates as an SFU with server-side bandwidth estimation.

Media Processing Pipeline

Performs server-side operations including adaptive bitrate transcoding, simulcast layer selection, audio mixing for large meetings, and noise cancellation. Enables heterogeneous client quality without P2P negotiation.

Caption Service

Real-time speech-to-text using Google’s ASR models. Provides live captions in 70+ languages with speaker attribution. Transcripts are saved to Google Docs automatically.

Recording Service

Captures meeting audio/video server-side and encodes to a composite recording. Stored in the organizer’s Google Drive with automatic access sharing to participants.

Live Stream Service

Converts the meeting into an HLS/DASH stream for up to 100,000 viewers. Uses Google’s CDN for distribution with ~15-second latency for live audiences.

Data Model

Loading diagram...
Google Meet — Entity relationship diagram

WebRTC and OASIS Media Routing

Meet is built entirely on WebRTC, the open standard for real-time communication in browsers. This means no plugin or desktop app is required — any modern browser can join a meeting.

OASIS is Google’s custom media relay infrastructure, deployed at 200+ edge Points of Presence (PoPs) globally. When a participant sends video, it travels to the nearest PoP, then traverses Google’s private backbone (not the public internet) to reach other participants’ nearest PoPs.

Simulcast: Each client sends multiple quality layers of their video (e.g., 720p, 360p, 180p). The OASIS router selects which layer to forward to each recipient based on their available bandwidth and display size. This avoids server-side transcoding for most cases.

Bandwidth estimation: OASIS performs server-side bandwidth estimation for each participant using REMB/transport-cc feedback. When a participant’s network degrades, the router instantly switches to a lower simulcast layer — the sender doesn’t need to change anything.

Loading diagram...
WebRTC and OASIS Media Routing

Server-side Noise Cancellation

Meet performs server-side noise cancellation using a deep learning model, a differentiator from most competitors that rely on client-side processing.

Why server-side?: Running the ML model server-side means it works on every device — including low-powered Chromebooks and phones — without draining the battery. It also ensures consistent quality regardless of client hardware.

Model architecture: A lightweight RNN-based model processes audio frames in real time with <10ms additional latency. It separates human speech from background noise (typing, construction, pets, etc.).

Deployment: The model runs on Google’s TPU infrastructure at the media processing layer. Each audio stream is processed independently before being forwarded to other participants.

Google Workspace Integration

Meet’s deep integration with Google Workspace is a core architectural decision that shapes its design.

Calendar-native: Meetings are created as Calendar events. The meeting ID and join link are embedded in the event, and Calendar handles invitations, reminders, and RSVP tracking. There’s no separate meeting management system.

Gmail integration: Meet links appear in Gmail, and users can join meetings directly from email threads. Meeting notes are auto-linked to Calendar events and stored in Google Docs.

Drive integration: Recordings and transcripts are automatically saved to the organizer’s Google Drive with appropriate sharing permissions inherited from the Calendar event.

Authentication: Meet uses Google’s centralized identity system. Workspace admins control meeting policies (who can join, recording permissions, etc.) via the Admin Console, which propagates to Meet through Google’s policy engine.

Architectural Tradeoffs

WebRTC standard over proprietary protocol

Pros

  • +Works in any browser — no installation needed
  • +Open standard with broad ecosystem support
  • +Rapid iteration on web platform features

Cons

  • −Constrained by browser WebRTC implementation differences
  • −Less control over codec selection than proprietary solutions
  • −Browser updates can introduce regressions

Server-side media processing over client-side

Pros

  • +Consistent quality across all devices
  • +Enables features on low-powered hardware
  • +Centralized noise cancellation and transcription

Cons

  • −Higher server infrastructure cost
  • −Adds a few ms of latency per hop
  • −Requires massive GPU/TPU fleet for ML inference

Tight Workspace integration over standalone product

Pros

  • +Seamless user experience within the ecosystem
  • +Shared identity, permissions, and storage
  • +Reduces separate infrastructure needs

Cons

  • −Less appealing to non-Google Workspace users
  • −Feature coupling — Workspace outages affect Meet
  • −Harder to use in mixed-ecosystem organizations

Learn From Google Meet

Copy a learning context prompt for an AI assistant. It keeps assumptions visible and asks for tradeoffs, cost drivers, failure modes, and what to measure before adding complexity.

Explore More Case Studies