Functional Requirements:
- "What's the expected meeting size? 1-on-1, small groups, or large webinars?"
- "Do we need recording functionality?"
- "Should we support screen sharing and file sharing?"
- "Do we need mobile app support or just web?"
- "Are there any specific integrations required (calendar, CRM)?"

Non-Functional Requirements:
- "What's the expected scale? How many concurrent users?"
- "What's the acceptable latency for real-time communication?"
- "What are the availability requirements?"
- "Are there specific compliance requirements (HIPAA, GDPR)?"
- "What's the expected global distribution?"

Example Calculation:
- 100M registered users
- 10% daily active users = 10M DAU
- Peak concurrent users = 20% of DAU = 2M
- Average meeting size = 4 participants
- Concurrent meetings = 2M / 4 = 500K meetings

Bandwidth Calculation:
- Video (720p): 2 Mbps per participant
- Audio: 64 kbps per participant
- Per meeting (4 participants): 8.25 Mbps
- Total bandwidth: 500K × 8.25 Mbps = 4.125 Tbps

Client Apps → Load Balancer → API Gateway → Core Services
                                          ↓
                                    [Signaling] [Media] [Recording]
                                          ↓
                                    Database Layer

// Show understanding of WebRTC flow
"The WebRTC connection establishment follows this pattern:
1. Signaling server exchanges offer/answer (SDP)
2. ICE candidates are gathered and exchanged
3. DTLS handshake establishes secure connection
4. SRTP encrypts media streams
5. Media flows directly between peers or via SFU"

"The main bottlenecks are:
1. WebSocket connection limits per server
2. Media processing CPU requirements
3. Network bandwidth for large meetings
4. Database write scaling for real-time updates

Solutions:
- Connection pooling with sticky sessions
- SFU cascading for large meetings
- Adaptive bitrate streaming
- Read replicas and caching"

1. Acknowledge the challenge: "This is a webinar scenario, not interactive meeting"

2. Architecture choice: "I'd use a hybrid approach:
   - Small group of presenters (5-10) use SFU for interaction
   - Large audience receives one-way stream via CDN
   - Separate chat service for Q&A"

3. Technical details:
   - "Use HLS or DASH for viewer distribution"
   - "3-5 second latency acceptable for viewers"
   - "Presenter audio/video mixed into single stream"
   - "CDN edge servers for global distribution"

4. Fallback plan: "If interactive features needed, cascade multiple SFUs"

Network Level:
- Use WebRTC with UDP transport
- Deploy TURN servers globally for NAT traversal
- Implement adaptive bitrate streaming
- Choose optimal routing paths

Application Level:
- Minimize signaling round trips
- Use SFU instead of MCU (no transcoding delay)
- Implement jitter buffers with adaptive sizing
- Prioritize audio over video for quality

Infrastructure Level:
- Edge computing for WebRTC signaling
- Regional media servers
- Direct peering with ISPs
- Dedicated network connections for high-volume regions

PostgreSQL (ACID compliance needed):
- User accounts and authentication
- Meeting metadata and scheduling
- Permissions and roles
- Recording metadata

Redis (Fast access, temporary data):
- Active session state
- WebRTC signaling cache
- Real-time chat messages
- Presence information

Cassandra (Time-series, high write volume):
- Meeting analytics and metrics
- Audit logs
- Call quality data
- Usage statistics

Object Storage (S3):
- Recording files
- Shared documents
- User avatars

Detection:
- WebRTC connection state monitoring
- Heartbeat/ping mechanisms
- Network quality metrics tracking

Recovery Strategies:
- Automatic ICE restart for connection recovery
- Exponential backoff for reconnection attempts
- Graceful degradation (audio-only mode)
- Local recording during disconnection

User Experience:
- Visual indicators for connection quality
- Automatic mute during poor connection
- Buffering for temporary network issues
- Seamless rejoin experience

1. Signaling Phase:
   - Client A creates RTCPeerConnection
   - Generates offer (SDP) with media capabilities
   - Sends offer to Client B via signaling server
   - Client B creates answer (SDP) and sends back

2. ICE Gathering:
   - Both clients gather ICE candidates (host, STUN, TURN)
   - Exchange candidates via signaling server
   - Test connectivity between candidate pairs

3. DTLS Handshake:
   - Establish secure connection using DTLS
   - Exchange certificates and verify fingerprints
   - Derive SRTP keys for media encryption

4. Media Flow:
   - Start sending encrypted media (SRTP)
   - Monitor connection quality and adapt
   - Handle network changes with ICE restart

Server-Side Recording (Recommended):

1. Media Composition:
   - Receive all participant streams at media server
   - Use FFmpeg or similar for real-time composition
   - Support multiple layouts (grid, speaker, custom)

2. Encoding Pipeline:
   - H.264 encoding for compatibility
   - Multiple quality outputs (720p, 1080p)
   - Audio mixing with noise suppression

3. Storage Strategy:
   - Stream directly to object storage (S3)
   - Chunked uploads for reliability
   - Metadata tracking for playback

4. Post-Processing:
   - Generate thumbnails and previews
   - Create searchable transcripts
   - Apply retention policies

Alternative: Distributed Recording
- Each participant records locally
- Upload chunks during meeting
- Server stitches together post-meeting

Transport Security:
- TLS 1.3 for all HTTP/WebSocket connections
- DTLS-SRTP for WebRTC media encryption
- Certificate pinning for mobile apps

Application Security:
- JWT tokens with short expiration
- Multi-factor authentication
- Role-based access control
- Meeting passwords and waiting rooms

Data Protection:
- End-to-end encryption for sensitive meetings
- PII data minimization
- Secure key management (HSM)
- Regular security audits

Monitoring:
- Real-time threat detection
- Anomaly detection for meeting bombing
- Audit logging for compliance
- Incident response automation

Battery Optimization:
- Lower frame rates (15fps vs 30fps)
- Reduced resolution (480p default)
- Hardware encoding when available
- Background mode optimizations

Network Optimization:
- Aggressive adaptive bitrate
- Audio-only mode for poor connections
- Efficient codec selection (H.264 hardware)
- Connection type detection (WiFi vs cellular)

User Experience:
- Touch-optimized interface
- Simplified feature set
- Offline meeting scheduling
- Push notifications for meeting reminders

Technical Implementation:
- Native WebRTC libraries
- Platform-specific optimizations
- Memory management
- Thermal throttling awareness

Real-Time Metrics:
- WebRTC stats API for connection quality
- Packet loss, jitter, and RTT monitoring
- Frame rate and resolution tracking
- Audio quality metrics

User Experience Metrics:
- Time to join meeting
- Connection success rate
- Call drop rate
- User satisfaction scores

Infrastructure Monitoring:
- Server CPU and memory usage
- Network bandwidth utilization
- Database performance metrics
- CDN cache hit rates

Debugging Tools:
- WebRTC internals (chrome://webrtc-internals)
- Network trace analysis
- Media server logs correlation
- User session replay for issues

Phase 1: Basic video calling (P2P)
Phase 2: Add server infrastructure (SFU)
Phase 3: Scale to large meetings
Phase 4: Add advanced features (recording, chat)
Phase 5: Global distribution and optimization

Instead of: "I'll use Redis for caching"
Say: "I'll use Redis for session state because:
- Sub-millisecond latency for real-time updates
- Built-in pub/sub for WebSocket message routing
- Automatic expiration for session cleanup
- High availability with Redis Cluster"

SFU vs MCU Trade-off:
"SFU preserves video quality and scales better, but uses more client bandwidth.
MCU reduces client load but degrades quality and has server CPU limits.
For our use case of 100-person meetings, SFU is better because..."

Common Edge Cases:
- Network partitions and split-brain scenarios
- Rapid participant join/leave (meeting bombing)
- Server failures during active meetings
- Cross-platform compatibility issues
- Firewall and NAT traversal problems

Production Considerations:
- Monitoring and alerting strategy
- Deployment and rollback procedures
- Capacity planning and auto-scaling
- Disaster recovery and backup plans
- Cost optimization strategies