DEV Community

Cover image for EdTech Platform Architecture, Lessons from Real Builds
Waqar Habib
Waqar Habib Subscriber

Posted on • Originally published at waqarhabib.com

EdTech Platform Architecture, Lessons from Real Builds

#edtech #architecture #react #typescript

EdTech has unique technical requirements that general-purpose web app architecture doesn't prepare you for. Real-time collaboration, video delivery at scale, progress tracking across complex learning paths, accessibility compliance under Section 508 and WCAG 2.1, the combination creates architectural challenges that only become apparent when you're building for real educational institutions.

Here's what actually matters when architecting an EdTech platform for the US market.

Concurrent Users During Scheduled Events

General SaaS products have relatively predictable traffic. EdTech platforms get slammed during scheduled events: the Monday morning class login spike, the Sunday night homework rush, the exam period where every student in a district hits the platform simultaneously.

Your architecture needs to handle 10x normal traffic for short, predictable bursts. The implications:

Horizontal scaling must be automatic and fast. ECS with Application Auto Scaling configured to scale based on CPU and request count, not memory alone. With containers, you can go from 5 to 50 instances in under 2 minutes if your scaling policies are aggressive enough.

# ECS Auto Scaling configuration
resource "aws_appautoscaling_policy" "ecs_scale_up" {
  policy_type        = "TargetTrackingScaling"

  target_tracking_scaling_policy_configuration {
    target_value = 60.0 # Scale when CPU hits 60%

    customized_metric_specification {
      metric_name = "RequestCountPerTarget"
      namespace   = "AWS/ApplicationELB"
      statistic   = "Sum"
    }

    scale_in_cooldown  = 300  # 5 min before scaling in (avoid flapping)
    scale_out_cooldown = 30   # 30 sec to scale out (be aggressive on the way up)
  }
}
Enter fullscreen mode Exit fullscreen mode

Database read replicas for heavy read loads. During class time, 90% of database queries are reads, students loading content, checking progress, retrieving assignments. Route reads to read replicas and reserve the primary for writes.

Real-Time Collaboration Architecture

EdTech products increasingly need real-time features: live classroom tools, collaborative documents, shared whiteboards. The technology stack depends on the interaction pattern:

Low-frequency updates (quiz responses, progress saves):
  → HTTP polling every 5-10 seconds is fine

Medium-frequency updates (chat, activity feed):
  → WebSockets via Socket.io

High-frequency updates (live cursor collaboration, whiteboard drawing):
  → WebRTC for peer-to-peer, or WebSockets with a CRDT library
Enter fullscreen mode Exit fullscreen mode

For WebSocket at scale, don't use a single Socket.io server, use Socket.io with Redis adapter so WebSocket connections can be distributed across multiple nodes:

import { Server } from 'socket.io';
import { createAdapter } from '@socket.io/redis-adapter';
import { createClient } from 'redis';

const pubClient = createClient({ url: process.env.REDIS_URL });
const subClient = pubClient.duplicate();

await Promise.all([pubClient.connect(), subClient.connect()]);

const io = new Server(httpServer);
io.adapter(createAdapter(pubClient, subClient));

// Now events published on one server instance are received by clients
// connected to other instances, works across your entire ECS cluster
Enter fullscreen mode Exit fullscreen mode

Video Delivery Architecture

Video is the backbone of most EdTech platforms and the most expensive thing to get wrong. Serving video files directly from S3 doesn't scale and destroys your AWS data transfer budget.

The correct architecture:

Content Upload:
  Instructor uploads → S3 raw storage → Lambda trigger → MediaConvert job
  → Transcoded to HLS (multiple bitrates) → CloudFront distribution

Content Delivery:
  Student requests video → CloudFront edge (cached near the student)
  → Signed URL with expiry (prevent sharing/leeching)
  → Adaptive bitrate streaming (HLS) → adjusts quality to connection speed
Enter fullscreen mode Exit fullscreen mode 
// Generate signed CloudFront URL for protected video content
import { getSignedUrl } from '@aws-sdk/cloudfront-signer';

async function getVideoUrl(videoKey: string, studentId: string): Promise<string> {
  // Log video access for completion tracking
  await trackVideoAccess(videoKey, studentId);

  return getSignedUrl({
    url: `https://${process.env.CLOUDFRONT_DOMAIN}/videos/${videoKey}/manifest.m3u8`,
    keyPairId: process.env.CLOUDFRONT_KEY_PAIR_ID,
    privateKey: process.env.CLOUDFRONT_PRIVATE_KEY,
    dateLessThan: new Date(Date.now() + 3600 * 1000).toISOString(), // 1 hour expiry
  });
}
Enter fullscreen mode Exit fullscreen mode

Learning Progress Tracking

Progress tracking sounds simple until you're tracking completion across: individual lessons, modules, courses, learning paths, certifications, with prerequisites, prerequisites with minimum scores, and time-based unlocking.

The data model that handles this:

-- Enrollment tracks the student-course relationship
CREATE TABLE enrollments (
  id UUID PRIMARY KEY,
  student_id UUID REFERENCES users(id),
  course_id UUID REFERENCES courses(id),
  enrolled_at TIMESTAMP,
  completed_at TIMESTAMP,
  UNIQUE(student_id, course_id)
);

-- Progress tracks individual content item completion
CREATE TABLE progress (
  id UUID PRIMARY KEY,
  enrollment_id UUID REFERENCES enrollments(id),
  content_item_id UUID REFERENCES content_items(id),
  status VARCHAR(20) CHECK (status IN ('not_started', 'in_progress', 'completed')),
  score DECIMAL(5,2),       -- quiz score if applicable
  time_spent_seconds INT,
  started_at TIMESTAMP,
  completed_at TIMESTAMP,
  UNIQUE(enrollment_id, content_item_id)
);

-- Prerequisites: content_item B requires content_item A with min score
CREATE TABLE prerequisites (
  content_item_id UUID REFERENCES content_items(id),
  requires_item_id UUID REFERENCES content_items(id),
  minimum_score DECIMAL(5,2) DEFAULT NULL
);
Enter fullscreen mode Exit fullscreen mode

FERPA Compliance for US Educational Data

If your EdTech platform handles data for US students under 18 in a school setting, FERPA applies. Key developer requirements:

  • Student educational records cannot be shared with third parties without parental consent (or the student's own consent if 18+)
  • Directory information (name, email) can be shared only if the institution has given proper notice
  • Every third-party service receiving student data needs a formal School Official exception or data processing agreement
  • Parents have the right to access and correct their child's educational records, build this capability in from the start

In practice: don't pipe student data to Google Analytics, Mixpanel, or Segment without a proper FERPA agreement with those vendors. Many edtech companies have learned this the hard way.

Accessibility Is Not Optional

US educational institutions are bound by Section 508 and often require WCAG 2.1 AA compliance in procurement contracts. If you're selling to US school districts, inaccessible software will fail procurement review.

Practical checklist for EdTech accessibility:

  • All video content has captions (auto-captions from AWS Transcribe, then human review)
  • All images have meaningful alt text
  • All interactive elements are keyboard navigable
  • Color contrast ratio meets WCAG AA (4.5:1 for normal text)
  • Screen reader testing with NVDA/JAWS before launch
  • Focus management in single-page app routing

EdTech architecture decisions made early, especially around video delivery, real-time features, and compliance, determine whether your platform can scale to serve real US institutions or stays a prototype.

I've built EdTech platforms for US educational markets, including compliance with FERPA and Section 508. Learn more at waqarhabib.com/industries/edtech-development.

Originally published at waqarhabib.com

Top comments (0)