Real-Time-Chat-Platform + WebRTC Signaling + Minimal SFU

1) Product requirement

1.1 Vision

Build a production-grade real-time communication platform that supports:

• Chat (channels + DMs), typing, read receipts, message history
• Presence (online/offline/last seen)
• Calls (audio/video) via WebRTC, with a reliable signaling layer
• Optional: a Minimal SFU to scale calls beyond P2P This mirrors Stream’s core domains: chat API + edge-friendly real-time infrastructure + (optionally) video SFU.

1.2 Target Users & Personas

1. End User

• Wants fast chat + reliable calls
• Expects instant delivery, message history, stable reconnects

2. App Developer (your “customer”)

• Integrates via API + SDK
• Wants stable public APIs, docs, versioning, predictable behavior

3. Operator (SRE mindset)

• Needs observability, rate limiting, abuse prevention, rollouts

1.3 Core Use Cases

Chat

• Create channel, invite users, send messages
• Real-time updates via WebSocket
• Fetch history with pagination
• Typing indicators
• Read receipts

Presence

• User online/offline (heartbeat)
• “last active”
• presence updates to channel members

Calls (WebRTC)

• Start call in a channel/DM
• Join/leave
• WebRTC signaling: offer/answer + ICE candidates
• Handle reconnect, renegotiation, ICE restart
• Optional: escalate to SFU for group calls

1.4 Product Scope

MVP (must-have)

Chat

• DM + Channel messaging
• Message history (persisted)
• WebSocket events for real-time message delivery
• Idempotent message send (no duplicates)

Presence

• Heartbeats
• Online/offline status
• Presence change events

WebRTC Signaling

• Call sessions (create/join/leave)
• Offer/Answer exchange
• Trickle ICE candidates
• Basic permissions (only members can join)

V1 (strong for interviews)

• Read receipts
• Typing events (debounced)
• Offline message delivery semantics (history fetch + last seen offsets)
• Rate limiting & abuse prevention
• SDKs (Go + JS)

Optional (differentiator)

Minimal SFU

• 1 room, N participants
• Forward tracks to all others (no mixing)
• Basic subscription management
• Basic bandwidth considerations documented

2) Technical Requirements

2.1 System Architecture (services)

Required services (Go)

API Gateway / Edge

• REST endpoints + WebSocket endpoint
• Auth, rate limiting, request validation
• Routes to internal services

Chat Service

• Persist messages to Postgres
• Publish real-time events (to WS hub via Redis PubSub/NATS)
• Read receipts + typing events (optional)

Presence Service

• Heartbeat ingestion
• Presence state stored in Redis with TTL
• Presence change events

Call/Signaling Service

• Manages call sessions (DB)
• Signaling message relay (WS → target participants)
• Enforces signaling state machine per participant

Optional service

SFU Service

• Pion WebRTC based
• Receives publisher tracks
• Forwards to subscribers

2.2 Protocols

• REST (JSON) for CRUD operations
• WebSocket for real-time events:
  • chat events
  • presence events
  • signaling events
• Optional: gRPC internal service communication (not required, but nice)

2.3 Authentication & Authorization

Auth

• JWT access token (or opaque token with introspection)
• Token includes user_id, tenant_id (optional), roles

Authorization rules

• Only members can:
• read/write channel messages -receive channel events
• join call sessions for that channel
• Server validates membership on:
  • REST calls
  • WS subscriptions
  • signaling messages

4) Engineering Milestones (practical build order)

• Chat REST + Postgres + idempotency
• WebSocket hub + channel subscriptions + message events
• Presence (Redis TTL + WS updates)
• Call sessions (DB + join/leave events)
• WebRTC signaling (offer/answer/ICE + state machine)
• SDKs (Go + JS)
• Load tests + observability
• Optional SFU

Infrastructure

• Postgres / CockroachDB → persistence
• Redis → presence, rate limiting, pub/sub
• WebSockets → real-time events
• Docker / Kubernetes → deployment

SDKs

• Go SDK
• JavaScript SDK

SDKs expose:

• Chat APIs
• Presence
• Call lifecycle
• WebSocket subscriptions
• Public API design & versioning are first-class concerns.

Production-Grade Architecture Enhancements

Envelope Calculations and Capacity Planning

Target Scale: 200M Monthly Active Users, 110M Daily Active Users

Connection Capacity per Node:

• Target: 50,000 concurrent WebSocket connections per node (optimized Go implementation)
• Memory per connection: ~4KB (optimized connection state + buffers)
• Total WebSocket memory: 200MB per node
• CPU overhead: ~0.05% per 100 connections under normal load
• Network bandwidth: ~500Mbps per node for 50K active users

Global Infrastructure Requirements:

• WebSocket Nodes: 2,200 nodes globally (110M DAU / 50K per node)
• Application Servers: 1,000+ nodes across all regions
• Database Clusters: 50+ PostgreSQL clusters with read replicas
• Redis Clusters: 100+ Redis clusters for caching and pub/sub
• CDN: Global CDN with 200+ edge locations

Database Capacity Planning:

• Messages table growth: ~500TB per month (assuming 50 messages per DAU)
• Total storage: ~6PB annually with compression and archiving
• Read/write ratio: 90/10 (heavy read workload at this scale)
• Connection pools: 100-200 connections per service cluster
• Query performance targets: <5ms p95 for message retrieval with proper indexing

Redis Memory Requirements:

• Presence data: ~200 bytes per online user (~22GB for 110M users)
• Rate limiting: ~100 bytes per user per minute (~11GB active)
• Pub/sub buffering: ~10GB per region for message distribution
• Session data: ~1KB per active session (~110GB total)
• Total Redis memory: ~500GB globally across all clusters

Network Envelope:

• Average message size: 500 bytes (including metadata)
• Peak message rate: 2M messages/second globally during peak hours
• WebSocket overhead: ~15% additional bandwidth (optimized)
• Total bandwidth: ~10Gbps globally during peak load
• CDN bandwidth: ~100Gbps for media content and API responses

Infrastructure Sizing (Global):

• Compute: 10,000+ CPU cores across all services
• Memory: 50TB+ RAM across all nodes
• Storage: 10PB+ with replication and backups
• Network: 100Gbps+ aggregate bandwidth
• Estimated monthly cost: $2-5M on major cloud providers

Regional Distribution (5 major regions):

• US-East: 40% of traffic (44M DAU)
• EU-West: 25% of traffic (27.5M DAU)
• Asia-Pacific: 20% of traffic (22M DAU)
• US-West: 10% of traffic (11M DAU)
• Other regions: 5% of traffic (5.5M DAU)

Additional Non-Functional Requirements

Availability and Reliability:

• 99.99% uptime SLA (52.6 minutes downtime per year)
• Zero-downtime deployments with canary releases across regions
• Automatic failover within 10 seconds using health checks
• Multi-region active-active with automatic traffic shifting
• Data replication with RPO < 10 seconds, RTO < 30 seconds

Security Enhancements:

• End-to-end encryption for all messages using Signal Protocol
• API rate limiting: 10,000 requests/minute per user with burst allowance
• Advanced DDoS protection with traffic analysis and ML-based detection
• Comprehensive audit logging for all operations with 2-year retention
• SOC2 Type II, GDPR, CCPA compliance with automated data governance
• Zero-trust security model with service mesh encryption

Monitoring and Observability:

• 100% distributed tracing with 1% sampling for performance analysis
• Real-time alerting with <30 second detection time
• Comprehensive dashboards for business and technical metrics
• Automated incident response with runbook automation
• Capacity planning with ML-based forecasting
• Security monitoring with SIEM integration

Data Consistency and Durability:

• ACID transactions with distributed consensus (Raft/Paxos)
• Event sourcing for complete audit trails and replay capability
• Cross-region data synchronization with conflict resolution
• Backup retention: 7 years with point-in-time recovery
• Data archiving with automated lifecycle management
• Disaster recovery with <1 hour RTO globally

Performance Optimizations for Hyperscale:

Memory Management:

• Object Pooling: Reuse message objects, connection structs
• Zero-Copy Operations: Minimize memory allocations in hot paths
• Memory-Mapped Files: For large data structures and caching
• Garbage Collection Tuning: Optimized GC settings for low latency

Network Optimizations:

• Connection Multiplexing: HTTP/2 and gRPC for internal communication
• Message Compression: Protocol buffer compression for internal messages
• TCP Optimization: Custom TCP settings for WebSocket connections
• Load Balancing: Consistent hashing with bounded loads

Database Optimizations:

• Query Optimization: Prepared statements, query plan caching
• Index Strategy: Covering indexes, partial indexes for large tables
• Partitioning: Time-based and hash-based table partitioning
• Connection Pooling: PgBouncer with transaction-level pooling

Caching Strategy:

• Multi-Level Caching: L1 (in-memory), L2 (Redis), L3 (CDN)
• Cache Warming: Proactive cache population for hot data
• Cache Invalidation: Event-driven cache invalidation with versioning
• Bloom Filters: Reduce cache misses for non-existent data

Monitoring and Observability at Scale:

• Distributed Tracing: Jaeger with 0.1% sampling rate
• Metrics Collection: Prometheus with custom metrics for business logic
• Log Aggregation: ELK stack with structured logging
• Real-time Dashboards: Grafana with alerting on SLA violations
• Capacity Planning: ML-based forecasting for resource allocation

Performance Optimization Strategies

Caching Layers:

• L1 Cache: In-memory LRU cache per service instance
• L2 Cache: Redis cluster for shared caching
• CDN: Static assets and API responses with appropriate TTL
• Database Query Cache: Prepared statements and query result caching

Message Processing Optimization:

• Message Batching: Process multiple messages in single database transaction
• Async Processing: Non-critical operations handled asynchronously
• Content Compression: Gzip compression for large message payloads
• Message Deduplication: Bloom filters for duplicate detection

WebSocket Optimization:

• Connection Pooling: Reuse connections for multiple subscriptions
• Message Compression: Per-message deflate for bandwidth optimization
• Heartbeat Optimization: Adaptive heartbeat intervals based on activity
• Event Filtering: Client-side filtering to reduce unnecessary traffic