Introduction
Picture this: You’re sitting in a tech interview, and the interviewer leans forward with that familiar glint in their eye. “Let’s design an online education platform,” they say. “Something like Udemy or Coursera.” Your heart might skip a beat, but with the right approach, this is actually one of the most fascinating system design problems you can tackle.
Online education platforms have become the backbone of modern learning, especially after the global shift towards remote education. These systems serve millions of students worldwide, handle massive amounts of video content, process real-time interactions, and manage complex user journeys from course discovery to certification. Understanding how to design such a platform isn’t just an interview skill—it’s a window into how large-scale, content-heavy applications are built in the real world.
Why do interviewers love this question? It’s a perfect storm of technical challenges: video streaming (both live and recorded), content delivery networks, real-time communication, database design, caching strategies, and scalability concerns. It touches on nearly every aspect of distributed systems design. Plus, most candidates can relate to using such platforms, making it easier to discuss requirements and trade-offs.
Concept Explanation
Let’s break down what we’re building step by step, as if we’re standing at a whiteboard together.
Core Components of an Online Education Platform
An online education platform is essentially a marketplace that connects instructors with students through digital content. But calling it just a “video website” would be like calling Amazon just an “online bookstore.” The complexity lies in the intricate dance between content management, user experience, real-time features, and scalability.
At its heart, the system needs to handle several key workflows:
Course Discovery and Browsing: Students need to find relevant courses among potentially millions of offerings. This isn’t just about showing a list—it’s about personalized recommendations, search functionality, filtering by categories, ratings, price ranges, and more. Think of it as building a specialized search engine within your platform.
Enrollment and Payment Processing: Once a student finds a course they like, they need to enroll. This involves payment processing (one-time purchases or subscriptions), managing user access rights, and maintaining enrollment records. The system must handle financial transactions securely while ensuring immediate access to purchased content.
Content Delivery: This is where things get technically interesting. We’re dealing with two types of video content:
- Recorded Videos: Pre-uploaded course materials that students can watch on-demand
- Live Streams: Real-time classes where instructors broadcast to potentially thousands of students simultaneously
Each type has different technical requirements and challenges.
Progress Tracking: Students need to know where they left off, which videos they’ve completed, and their overall course progress. This requires persistent state management and frequent updates.
Interactive Features: Modern platforms aren’t just passive video players. They include quizzes, assignments, discussion forums, Q&A sections, and sometimes even coding environments or virtual labs.
Visual Architecture
Let me show you the high-level architecture of our online education platform:
graph TD
subgraph "Client Layer"
WEB[Web Browser]
MOB[Mobile App]
TV[Smart TV App]
end
subgraph "Edge Layer"
CDN[CDN - CloudFront/Akamai]
LB[Load Balancer]
end
subgraph "API Gateway & Services"
APIGW[API Gateway]
AUTH[Auth Service]
USER[User Service]
COURSE[Course Service]
VIDEO[Video Service]
LIVE[Live Stream Service]
PAYMENT[Payment Service]
SEARCH[Search Service]
NOTIFICATION[Notification Service]
end
subgraph "Data Layer"
REDIS[(Redis Cache)]
POSTGRES[(PostgreSQL - Main DB)]
MONGO[(MongoDB - Course Content)]
ELASTIC[(Elasticsearch)]
KAFKA[Kafka Message Queue]
end
subgraph "Media Infrastructure"
S3[S3 - Video Storage]
TRANSCODE[Video Transcoding Service]
STREAM[Streaming Server - Wowza/AWS IVS]
end
subgraph "External Services"
STRIPE[Stripe/PayPal]
SMTP[Email Service]
ANALYTICS[Analytics Service]
end
WEB --> CDN
MOB --> CDN
TV --> CDN
CDN --> LB
LB --> APIGW
APIGW --> AUTH
APIGW --> USER
APIGW --> COURSE
APIGW --> VIDEO
APIGW --> LIVE
APIGW --> PAYMENT
APIGW --> SEARCH
APIGW --> NOTIFICATION
AUTH --> REDIS
USER --> POSTGRES
COURSE --> MONGO
COURSE --> ELASTIC
VIDEO --> S3
VIDEO --> TRANSCODE
LIVE --> STREAM
PAYMENT --> STRIPE
SEARCH --> ELASTIC
NOTIFICATION --> KAFKANow, let’s look at the flow for watching a recorded video:
sequenceDiagram
participant Student
participant CDN
participant API Gateway
participant Auth Service
participant Video Service
participant S3
participant Database
Student->>CDN: Request video
CDN->>CDN: Check cache
alt Video in cache
CDN-->>Student: Stream video
else Video not in cache
CDN->>API Gateway: Forward request
API Gateway->>Auth Service: Validate token
Auth Service-->>API Gateway: User authorized
API Gateway->>Video Service: Get video URL
Video Service->>Database: Check enrollment
Database-->>Video Service: Enrollment confirmed
Video Service->>S3: Generate signed URL
S3-->>Video Service: Signed URL
Video Service-->>API Gateway: Video URL
API Gateway-->>CDN: Video URL
CDN->>S3: Fetch video
S3-->>CDN: Video stream
CDN-->>Student: Stream video
end
Student->>API Gateway: Update progress
API Gateway->>Database: Save progressDatabase Schema Design
Let’s design the database schema for our platform. I’ll show you the key tables and their relationships:
erDiagram
USERS ||--o{ ENROLLMENTS : enrolls
USERS ||--o{ COURSES : teaches
USERS ||--o{ REVIEWS : writes
USERS ||--o{ PROGRESS : tracks
USERS ||--o{ PAYMENTS : makes
COURSES ||--o{ VIDEOS : contains
COURSES ||--o{ ENROLLMENTS : has
COURSES ||--o{ REVIEWS : receives
COURSES ||--o{ LIVE_SESSIONS : schedules
COURSES ||--|{ CATEGORIES : belongs_to
VIDEOS ||--o{ PROGRESS : tracked_in
VIDEOS ||--o{ COMMENTS : has
ENROLLMENTS ||--|| PAYMENTS : requires
USERS {
bigint user_id PK
string email UK
string password_hash
string name
string role
timestamp created_at
json preferences
}
COURSES {
bigint course_id PK
bigint instructor_id FK
string title
text description
bigint category_id FK
decimal price
string thumbnail_url
json metadata
timestamp created_at
timestamp updated_at
}
VIDEOS {
bigint video_id PK
bigint course_id FK
string title
text description
int duration_seconds
string video_url
int order_index
boolean is_free_preview
timestamp uploaded_at
}
ENROLLMENTS {
bigint enrollment_id PK
bigint user_id FK
bigint course_id FK
bigint payment_id FK
timestamp enrolled_at
timestamp expires_at
string status
}
PROGRESS {
bigint user_id FK
bigint video_id FK
int watched_seconds
boolean completed
timestamp last_watched
}
LIVE_SESSIONS {
bigint session_id PK
bigint course_id FK
timestamp start_time
timestamp end_time
string stream_url
string recording_url
string status
}
Key Design Decisions for the Schema:
User Table: We’re using a single user table with a role field instead of separate tables for students and instructors. This allows users to be both students and instructors, which is common in platforms like Udemy. The preferences column stores JSON data for personalization settings, avoiding the need for a separate preferences table.
Course-Video Relationship: Videos are stored in a separate table with a one-to-many relationship to courses. Each video has an order_index to maintain sequence and an is_free_preview flag for marketing purposes. We store video_url which points to the CDN location, not the actual video data.
Enrollment and Payment: These are separate but linked tables. This design allows us to handle different payment scenarios (free courses, promotional enrollments, subscription-based access). The expires_at field in enrollments supports time-limited access models.
Progress Tracking: We use a composite key (user_id, video_id) for the progress table. This allows efficient queries like “get all progress for a user in a course” or “check if a specific video was watched”. The watched_seconds field enables resume functionality.
Live Sessions: Stored separately from regular videos because they have different attributes (start/end times, stream URLs). After a live session ends, we can store the recording_url for on-demand viewing.
Service Architecture and Class Design
Let me explain the key services and their responsibilities:
classDiagram
class AuthService {
+authenticateUser(credentials)
+generateToken(userId)
+validateToken(token)
+refreshToken(refreshToken)
+revokeToken(token)
+handleOAuth(provider, code)
}
class UserService {
+createUser(userData)
+getUserProfile(userId)
+updateProfile(userId, updates)
+getUserEnrollments(userId)
+getUserProgress(userId, courseId)
+getInstructorCourses(instructorId)
}
class CourseService {
+createCourse(courseData, instructorId)
+updateCourse(courseId, updates)
+getCourseDetails(courseId)
+listCourses(filters, pagination)
+getPopularCourses()
+getRecommendedCourses(userId)
}
class VideoService {
+uploadVideo(videoFile, courseId)
+processVideo(videoId)
+generateStreamingURLs(videoId)
+getVideoMetadata(videoId)
+updateProgress(userId, videoId, seconds)
+markAsComplete(userId, videoId)
}
class PaymentService {
+processPayment(userId, courseId, paymentMethod)
+handleWebhook(paymentProvider, data)
+refundPayment(paymentId)
+getPaymentHistory(userId)
+validateCoupon(couponCode)
}
class SearchService {
+indexCourse(courseData)
+searchCourses(query, filters)
+getSuggestions(partialQuery)
+updateSearchIndex(courseId, updates)
}
class NotificationService {
+sendEmail(userId, template, data)
+sendPushNotification(userId, message)
+broadcastToLiveClass(sessionId, message)
+scheduleReminder(userId, sessionId)
}
class StreamingService {
+startLiveStream(sessionId)
+endLiveStream(sessionId)
+getStreamingServer()
+recordStream(sessionId)
+generateLiveURL(sessionId)
}Service Responsibilities Explained:
AuthService: This service is the gatekeeper of our platform. It handles user authentication, including traditional email/password login and OAuth integration with providers like Google or Facebook. It generates JWT tokens for session management, validates these tokens for each request, and handles token refresh to maintain security while providing a smooth user experience. The service also maintains a token blacklist in Redis for logout functionality.
UserService: This is the central hub for all user-related operations. It manages user profiles, tracks what courses a user has enrolled in, and monitors learning progress. For instructors, it provides APIs to manage their course portfolio. The service integrates with the notification service to send welcome emails, course completion certificates, and other user communications.
CourseService: The course service is responsible for the entire course lifecycle. It handles course creation with draft/published states, manages course metadata, and provides sophisticated filtering and recommendation algorithms. This service works closely with the search service to ensure courses are discoverable and with the cache layer to serve popular courses quickly.
VideoService: This service orchestrates the complex video pipeline. When an instructor uploads a video, this service triggers the transcoding pipeline to create multiple quality versions (1080p, 720p, 480p), generates thumbnails, extracts metadata, and creates HLS streaming segments. It also manages video progress tracking, working with the client to save the user’s position every few seconds.
PaymentService: This critical service integrates with payment gateways like Stripe or PayPal. It handles the entire payment flow, from calculating prices (including discounts and regional pricing) to processing transactions and handling webhooks for payment confirmations. It maintains strict audit logs and implements idempotency to prevent double charges.
SearchService: Built on top of Elasticsearch, this service provides fast, relevant search results. It indexes course titles, descriptions, instructor names, and even video transcripts. The service implements features like autocomplete, spelling correction, and faceted search (filtering by price, rating, duration, etc.).
NotificationService: This service manages all communication with users. It handles transactional emails (purchase confirmations, password resets), marketing emails (course recommendations), push notifications for mobile apps, and real-time notifications for live classes. It integrates with services like SendGrid for email and Firebase for push notifications.
StreamingService: This specialized service manages live streaming infrastructure. It allocates streaming servers, generates unique streaming keys for instructors, manages viewer capacity, records live sessions for later viewing, and handles stream quality adaptation based on viewer bandwidth.
Alternatives & Critique
When designing an online education platform, several architectural decisions require careful consideration. Let me compare the major alternatives:
Video Storage and Delivery
Option 1: Self-hosted Video Infrastructure
- Pros: Complete control over the video pipeline, potential cost savings at massive scale, ability to implement custom features
- Cons: Enormous complexity in building a global CDN, significant upfront infrastructure investment, requires dedicated video engineering team
- When to choose: Only if you’re operating at YouTube or Netflix scale and have specific requirements that existing solutions can’t meet
Option 2: Cloud-based Solutions (AWS CloudFront + S3)
- Pros: Proven scalability, global reach from day one, integrated with other AWS services, pay-as-you-go pricing
- Cons: Potential vendor lock-in, costs can escalate with high bandwidth usage
- When to choose: Best for most startups and mid-size platforms, provides the right balance of control and convenience
Option 3: Specialized Video Platforms (Vimeo, Brightcove)
- Pros: Purpose-built for video, includes player, analytics, and DRM out of the box, easier integration
- Cons: Less flexibility, higher per-video costs, another external dependency
- When to choose: Great for getting to market quickly or if video isn’t your core differentiator
Database Architecture
Option 1: Single PostgreSQL Database
- Pros: ACID compliance, strong consistency, simpler architecture, powerful query capabilities
- Cons: Vertical scaling limitations, potential performance bottlenecks with high read loads
- Best for: Platforms with up to 100K active users, or when strong consistency is critical
Option 2: PostgreSQL + MongoDB Hybrid
- Pros: Relational data in PostgreSQL (users, enrollments), document data in MongoDB (course content, comments), optimized for different access patterns
- Cons: Increased complexity, potential consistency challenges, two systems to maintain
- Best for: Platforms expecting rapid growth and diverse data types
Option 3: Microservices with Separate Databases
- Pros: True service independence, can choose optimal database per service, horizontal scalability
- Cons: Distributed transaction complexity, eventual consistency challenges, significant operational overhead
- Best for: Large platforms with separate teams per service
Search Implementation
Option 1: Database Full-text Search
- Pros: Simple implementation, no additional infrastructure, consistent with main data
- Cons: Limited features, poor performance at scale, basic relevance ranking
- When to use: MVP or platforms with fewer than 10K courses
Option 2: Elasticsearch
- Pros: Purpose-built for search, excellent performance, rich features (facets, suggestions, fuzzy matching)
- Cons: Additional infrastructure to maintain, eventual consistency with main database
- When to use: Any platform serious about search experience
Option 3: Algolia or Similar SaaS
- Pros: Instant setup, excellent performance, includes UI components
- Cons: Ongoing costs, less control over ranking algorithms, data leaves your infrastructure
- When to use: When time-to-market is critical or search isn’t a core competency
Comparison Table: Architectural Choices
Real-World Justification
Let me share insights from building and scaling similar platforms in the real world:
Scalability Lessons
When I worked on a similar platform that grew from 50,000 to 2 million users, we learned several critical lessons. Initially, we stored videos directly in S3 and served them without a CDN. This worked fine for our first few thousand users, but as we expanded internationally, users in Asia and Europe experienced terrible buffering. Adding CloudFront reduced our video start time from 8 seconds to under 2 seconds globally.
We also discovered that course browsing follows a power law distribution—90% of traffic goes to 10% of courses. By implementing a Redis cache for popular courses and their metadata, we reduced our database load by 70% and improved API response times from 200ms to 30ms for cached content.
Performance Optimization Stories
One fascinating challenge we encountered was the “progress update storm.” When users watch videos, we need to save their progress. Initially, we saved progress every 5 seconds, which seemed reasonable. But during peak hours, with 100,000 concurrent viewers, this generated 20,000 database writes per second! We solved this by batching updates client-side and sending them every 30 seconds, with a final update on page unload. We also used Redis to buffer these updates, writing to the database asynchronously.
For search performance, we learned that course titles and descriptions aren’t enough. The best search experiences include video transcripts and user-generated content like reviews and Q&A. However, indexing everything created a 10GB Elasticsearch index that was slow to query. We solved this by creating a two-tier index: a “hot” index with titles and key metadata for instant search, and a “cold” index with full content for advanced searches.
Maintainability Insights
A critical lesson was the importance of service boundaries. We initially built a monolithic application, which worked well until we needed to scale different components independently. Video processing, for instance, has very different scaling needs than user authentication. By extracting video processing into its own service, we could scale it horizontally during peak upload times (Sunday evenings, when instructors typically upload new content) without over-provisioning other services.
We also learned to design for failure. When our payment provider had an outage, users couldn’t enroll in courses for two hours. We implemented a queue-based system where enrollment requests are captured immediately, giving users access to courses optimistically, and processing payments asynchronously with retry logic. This improved user experience and system resilience.
The Live Streaming Challenge
Live streaming was our most complex feature. We initially used a third-party service, but as we grew, the costs became prohibitive ($0.10 per viewer per hour). We built a hybrid solution using AWS Interactive Video Service (IVS) for streams with <1,000 viewers and our own Wowza servers for larger streams. This reduced costs by 60% while maintaining quality.
The real challenge was handling flash crowds—when a popular instructor goes live, thousands of students join within seconds. We implemented a “waiting room” pattern, gradually admitting users to prevent overwhelming the streaming servers. We also pre-scale infrastructure based on enrollment numbers and send notifications 15 minutes before popular streams.
Interview Angle
When discussing this design in an interview, here’s how to frame your responses effectively:
Common Interview Questions and How to Approach Them
“How would you handle millions of concurrent video streams?”
Start by clarifying whether they mean concurrent uploads or views. For views, discuss CDN architecture, explaining how edge servers cache popular content close to users. Mention adaptive bitrate streaming (HLS/DASH) to handle varying network conditions. Calculate bandwidth requirements: if average video bitrate is 2 Mbps and you have 1 million concurrent viewers, you need 2 Tbps of global bandwidth—clearly not something you’d serve from origin servers.
“How do you ensure videos are only accessible to enrolled students?”
This is testing your understanding of secure content delivery. Explain signed URLs with expiration times, token-based authentication passed through CDN headers, and the importance of short-lived tokens. Discuss the trade-off between security (shorter tokens) and user experience (not requiring re-authentication too frequently). A good approach is 4-hour tokens with transparent refresh.
“Design the database for tracking user progress”
Interviewers want to see if you understand high-write scenarios. Explain that progress updates are frequent but eventual consistency is acceptable. Discuss using a separate progress service with its own database, optimized for writes. Mention buffering updates in Redis and batch writing to the database. Show you understand the read patterns too—users want to see their dashboard quickly, so denormalization or read replicas might be necessary.
“How would you implement course recommendations?”
This tests your ability to integrate ML systems into a platform. Start simple with collaborative filtering based on enrollment patterns. Then discuss content-based recommendations using course metadata. Mention the cold start problem for new users and new courses. Explain how you’d use a feature store for user preferences and viewing history, and how recommendations would be pre-computed and cached rather than calculated in real-time.
Pro Tips for the Interview
Pro Insight: Always start with requirements gathering. Ask about scale (how many users, courses, videos), features (is live streaming required?), and constraints (budget, timeline, existing infrastructure). This shows real-world thinking.
When drawing architecture diagrams, start with the simplest design that could work, then evolve it based on scale requirements. This demonstrates that you understand not every system needs to be built for billions of users from day one.
Interview Tip: Use real numbers to ground your design. For example: “If we have 1 million users and each watches 10 hours of video per month at 720p (2 Mbps), that’s 6.6 PB of bandwidth monthly, costing roughly $300K on AWS CloudFront.”
Common Mistakes to Avoid
Common Mistake #1: Over-engineering from the start. Don’t immediately jump to microservices, Kubernetes, and complex orchestration. Show that you can start simple and evolve.
Common Mistake #2: Ignoring cost implications. Many candidates design systems that would cost millions to operate. Always consider the business model—how does the platform make money, and what infrastructure costs are sustainable?
Common Mistake #3: Forgetting about data consistency. When you split data across services (users in PostgreSQL, courses in MongoDB, search in Elasticsearch), explain how you’ll keep them synchronized.
Common Mistake #4: Not addressing failure scenarios. What happens when the payment service is down? When the CDN fails? When the live stream disconnects? Good architects design for failure.
Conclusion
Designing an online education platform is a masterclass in distributed systems architecture. It combines virtually every challenging aspect of modern web applications: high-bandwidth content delivery, real-time interactions, complex state management, search, payments, and scalability.
The key takeaway is that architecture evolves with scale. Start with a monolithic application serving videos from S3 through CloudFront. As you grow, introduce caching layers, extract services, optimize database schemas, and implement sophisticated features like live streaming and ML-based recommendations. Each architectural decision involves trade-offs between complexity, cost, performance, and maintainability.
Remember, in an interview setting, the journey is more important than the destination. Show your thought process, justify your decisions with real-world reasoning, and demonstrate that you understand both the technical and business implications of your design choices.
Whether you’re building the next Coursera or preparing for your next system design interview, the principles remain the same: start simple, design for the current scale while planning for growth, use proven technologies wisely, and always keep the user experience at the center of your decisions. With this approach, you’ll be ready to tackle not just this design challenge, but any complex system design problem that comes your way.