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
WebSocket
Keep a bidirectional connection open for low-latency client and server messages.
CRDT
Let distributed replicas accept local edits and merge without conflicts.
Operational Transform
Transform concurrent edits so collaborative documents preserve user intent.
Pub/Sub
Broadcast events from publishers to many independent subscribers.
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
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
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.
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.