Case Study: NexusEd Real-Time EdTech Architecture for Live Tutoring

Problem Statement

Most edtech platforms struggle with one or more of these issues:

• high-latency live classes
• expensive third-party conferencing bills
• disconnected payments and session workflows
• poor mobile/browser compatibility for audio/video

NexusEd treats these as a product problem and built its own real-time architecture to provide an integrated classroom experience.

Architecture Breakdown

Client-side WebRTC architecture

The VideoCall.tsx component is the heart of the realtime experience:

• uses navigator.mediaDevices.getUserMedia for camera + mic
• uses navigator.mediaDevices.getDisplayMedia for screen sharing
• creates RTCPeerConnection objects per remote participant
• uses STUN servers from Google for ICE candidate exchange
• manages offers, answers and ICE using Socket.io events

This design gives NexusEd:

• low latency group calls
• native browser compatibility
• in-browser screen sharing
• a rich classroom UX inside the product

Signalling and presence

Socket.io supports:

• video-join, video-leave
• video-offer, video-answer, video-ice
• liveclass-started, notification, new-announcement

That means NexusEd can power:

• peer-to-peer classroom signalling
• real-time chat and group messaging
• live class start alerts
• backend-driven notifications across the app

Payments and checkout flow

The Razorpay integration uses useRazorpay() for:

• dynamic script loading
• server-side order creation via /payments/order
• client-side checkout and callback handling
• server-side verification via /payments/verify

This keeps payments:

• secure
• fast for students
• integrated with class enrolment

Delivery and data flow

NexusEd’s frontend is a Next.js app with:

• markdown-based blog publishing
• authenticated app routes for students, teachers, parents and admins
• next.config.ts remote image patterns for Cloudflare R2

The result is a modern edge-ready product with fast landing pages and a realtime app layer.

Architecture Diagram

graph LR
  Browser -->|HTTP| NextJS[Next.js Frontend]
  Browser -->|Socket.io| API[Backend Signalling]
  Browser -->|WebRTC| Browser
  API -->|Payments| Razorpay
  NextJS -->|Image Fetch| CloudflareR2[Cloudflare R2]

Trade-offs and decisions

• Chose WebRTC over third-party provider for cost and control
• Chose Socket.io over polling to keep classroom events instant
• Used native Razorpay checkout to support Indian payment methods
• Used Cloudflare R2 remote patterns for flexible asset hosting

Trade-offs:

• peer-to-peer video is best for small groups, so larger events may require a future TURN/MCU layer
• Razorpay adds a script dependency, but it is the strongest payment option in the market for Indian customers
• App Router complexity is accepted to achieve better SEO and future maintenance

Product value delivered

• real-time study rooms with video, audio and screen sharing
• live session signalling through socket.io
• payment flow integrated directly into course and live class pages
• notifications and dashboards for student progress and institute admin
• scalable markdown blog content system for product marketing

Results

• Built the realtime core in 8 weeks
• Delivered peer-to-peer video with screen share and mute/video controls
• Integrated Razorpay checkout with verification
• Set up Cloudflare R2 image delivery support
• Created a clean path from content marketing to product adoption via blog articles

What to take away

The NexusEd architecture shows that an edtech product can:

• use modern frontend tooling and still support real-time collaboration
• keep payments and live classrooms in the same product experience
• prepare for growth with a modular, decoupled stack