Bhupesh Kumar - Student Developer

Bhupesh

Student • Dev • Ailurophile

Current page: Unknown
← Back to Blog
2025-08-298 min read

How I Think Unacademy's Live Class Backend Works: A Technical Deep Dive

Understanding the architecture behind India's largest EdTech platform's real-time learning experience

BackendArchitectureReal-timeEdTech

Introduction

Ever wondered how Unacademy manages to stream live classes to millions of students simultaneously without breaking a sweat? After analyzing their user experience and building a similar system myself, I believe I've cracked the code behind their impressive backend architecture.

In this post, I'll walk you through what I think powers Unacademy's live streaming infrastructure, from the teacher's screen to millions of student devices.

The Challenge: One Teacher, Million Students

Imagine this scenario:

  • 1 Teacher conducting a live Physics class
  • 50,000+ students watching simultaneously across India
  • Real-time slide synchronization - when teacher changes slide, everyone sees it instantly
  • Video streaming with minimal latency
  • Interactive features like polls, chat, and Q&A

This isn't your typical web application. It's a real-time, distributed system operating at massive scale.

The SFU Architecture: Heart of Live Streaming

Based on my analysis, Unacademy likely uses an SFU (Selective Forwarding Unit) architecture:

Unacademy Live Class Architecture Diagram

What is SFU?

Unlike traditional streaming where the server processes/mixes streams (MCU), an SFU simply forwards the teacher's stream to students. Think of it as a smart traffic controller:

  • Teacher uploads once - sends video/slides to SFU server
  • SFU duplicates efficiently - forwards same stream to thousands of students
  • Bandwidth optimization - students receive optimized streams based on their network

The Technical Stack (My Hypothesis)

1. Session Management Layer

// Teacher creates a live class
POST /api/v1/session
{
  "title": "Physics - Laws of Motion",
  "scheduledTime": "2025-08-29T10:00:00Z"
}

The backend likely maintains:

  • Session state (inactive → active → ended)
  • Participant management (who's in the class)
  • Content synchronization (current slide, timestamp)

2. Content Distribution Network

When teachers upload slides or PDFs:

// PDF gets converted to images for faster loading
POST /api/v1/session/{sessionId}/slides/pdf
→ PDF to images conversion
→ Upload to CDN (AWS S3/CloudFront)
→ Return public URLs to all students

Why convert PDFs to images?

  • Faster loading on mobile devices
  • Consistent rendering across platforms
  • Better caching strategies

3. Real-time Communication

This is where the magic happens:

WebRTC + WebSocket Hybrid:

  • WebRTC for video/audio streaming (low latency)
  • WebSocket for control messages (slide changes, polls, chat)
// When teacher changes slide
websocket.broadcast({
  type: "SLIDE_CHANGE",
  sessionId: "xyz123",
  slideNumber: 5,
  timestamp: Date.now()
})

4. Scalability Solutions

Regional Edge Servers:

Load Distribution:

  • Multiple SFU instances per region
  • Intelligent routing based on student location
  • Auto-scaling during peak hours (7-9 PM typically)

The Student Experience Flow

Here's what happens when a student joins:

Authentication & Authorization

// Verify student has access to this class
const hasAccess = await checkSubscription(userId, sessionId)

Stream Connection

// Connect to nearest SFU server
const sfuEndpoint = await getOptimalServer(userLocation)
establishWebRTCConnection(sfuEndpoint)

Sync with Current State

// Get current slide, timestamp, chat history
const currentState = await getSessionState(sessionId)
syncUI(currentState)

Handling Scale: The Engineering Challenges

Challenge 1: Connection Management

Problem: 50,000 concurrent WebSocket connections

Solution: Connection pooling + event-driven architecture

Challenge 2: Bandwidth Costs

Problem: Streaming HD video to millions = expensive

Solution:

  • Adaptive bitrate streaming
  • Multiple quality options (360p, 720p, 1080p)
  • Regional CDN caching

Challenge 3: Real-time Synchronization

Problem: Ensuring all students see slide changes simultaneously

Solution:

// Timestamp-based synchronization
{
  "event": "slide_change",
  "slideId": "slide_5",
  "timestamp": 1704534000000,
  "bufferTime": 200 // 200ms buffer for network delays
}

Database Architecture (Speculation)

I believe they use a hybrid approach:

PostgreSQL/MySQL for:

  • User data, subscriptions
  • Class schedules, metadata
  • Historical data, analytics

Redis for:

  • Session state (current slide, active users)
  • Real-time features (chat, polls)
  • Caching frequently accessed data

Time-series DB (InfluxDB/TimeScale) for:

  • Video quality metrics
  • Connection health monitoring
  • Performance analytics

The Business Logic Layer

class LiveClassManager {
  async startClass(sessionId: string) {
    // Update session status
    await updateSessionStatus(sessionId, 'ACTIVE')
    
    // Notify all registered students
    await notificationService.broadcast({
      type: 'CLASS_STARTED',
      sessionId,
      message: 'Your class has started!'
    })
    
    // Initialize streaming infrastructure
    await streamingService.createRoom(sessionId)
  }
}

Security & Privacy Considerations

Stream Protection:

  • JWT tokens with expiration
  • Session-based access control
  • DRM for premium content

Privacy:

  • Students can't see each other's video
  • Selective audio permissions
  • Encrypted data transmission

Performance Optimizations

1. Lazy Loading

// Only load slides when needed
const preloadNext = async (currentSlide: number) => {
  preloadSlides([currentSlide + 1, currentSlide + 2])
}

2. Connection Health Monitoring

// Auto-reconnect on poor network
if (connectionQuality < threshold) {
  switchToLowerQuality()
  attemptReconnect()
}

3. Regional Optimization

  • Mumbai servers for Western India
  • Bangalore servers for Southern India
  • Delhi servers for Northern India

The Mobile Challenge

60% of Unacademy's traffic comes from mobile devices:

Challenges:

  • Limited bandwidth
  • Battery optimization
  • Network switching (WiFi ↔ 4G)

Solutions:

  • Aggressive video compression
  • Background streaming prevention
  • Smart quality adaptation

Future Enhancements (My Predictions)

AI-Powered Quality Adjustment

Automatically adjust video quality based on content type. Higher quality for mathematical equations, lower for talking head.

Edge Computing

Process some features locally on student devices. Reduce server load for interactive features.

Advanced Analytics

Real-time engagement tracking. Predictive scaling based on class popularity.

Conclusion: The Engineering Marvel

Unacademy's backend is likely a sophisticated orchestration of:

  • SFU-based streaming architecture
  • Microservices for different functionalities
  • Multi-region deployment
  • Real-time synchronization systems
  • Intelligent scaling mechanisms

The beauty lies not in any single technology, but in how these components work together to create a seamless learning experience for millions of students.

Building such a system requires deep understanding of distributed systems, real-time communication, and most importantly - the unique challenges of live educational content delivery.

What do you think? Have you worked on similar systems? I'd love to hear your thoughts on how you'd architect a platform like Unacademy!