real-time-virtual-classroom-platform@the-virtulab:~/case-study
EdTech 18 months 2021-2022

Real-Time Virtual Classroom Platform

@ The Virtulab — Senior Backend Developer (Solo)

Designing and deploying an entire EdTech backend — from first commit to production — as the sole backend engineer

0→1 Infrastructure Built
100% Backend Ownership
<200ms Stream Latency

$ cat PROBLEM.md

Building Production Infrastructure Solo at Startup Speed

The Virtulab needed a complete backend for their virtual classroom platform — video streaming, real-time collaboration, user management, and cloud infrastructure. As the only backend engineer, I had to architect, implement, and operate everything while maintaining startup velocity.

Key Challenges:

  • 🔴 No existing infrastructure — everything needed to be built from scratch
  • 🔴 Real-time video streaming with sub-200ms latency for interactive classrooms
  • 🔴 Multiple technology domains: streaming, databases, authentication, DevOps
  • 🔴 Had to balance building fast with building for scale

$ cat SOLUTION.md

Multi-Language Microservices on Google Cloud

I designed a polyglot microservices architecture that leveraged the right tool for each job, deployed on GKE with full CI/CD automation. The platform supported real-time video, audio, and screen sharing for hundreds of concurrent users.

Technical Approach:

1
Technology-Optimized Services

Different languages for different strengths: Node.js for real-time WebSocket connections, Python for ML-powered features, Java/Spring Boot for heavy computational tasks.

2
Hybrid Streaming Architecture

Combined WebRTC for peer-to-peer low-latency connections with Wowza/Agora.io for larger broadcast scenarios. RTMP ingestion for external streaming sources.

3
Event-Driven Processing

RabbitMQ for async workloads — video processing, notification delivery, analytics events. Celery workers for Python background jobs.

4
Full GCP Automation

Cloud Build for CI, GKE for orchestration, Cloud Armor for security. Complete Infrastructure as Code for reproducible deployments.

$ cat tech-stack.json

🚀 Core Technologies

Node.js / Express

Real-time APIs and WebSocket handling

Why: Async I/O excels at concurrent connections; fast iteration for API development

Python / Flask

ML features and data processing

Why: Rich ML ecosystem for recommendation engine and analytics

Java / Spring Boot

Core business logic and integrations

Why: Type safety and performance for complex computational tasks

🔧 Supporting Technologies

WebRTC Agora.io Wowza RabbitMQ PostgreSQL / MongoDB / Firestore

☁️ Infrastructure

Google Cloud Platform GKE (Kubernetes) Cloud Build / Cloud Deploy Cloud Armor

$ cat ARCHITECTURE.md

The platform used a layered architecture with specialized services for each domain:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
Frontend (Angular) ← API Gateway ← Load Balancer
     ┌──────────────────────────────────────────┐
     │              Service Mesh                 │
     │  ┌─────────┐  ┌─────────┐  ┌─────────┐   │
     │  │ Node.js │  │  Python │  │  Java   │   │
     │  │ RT APIs │  │    ML   │  │  Core   │   │
     │  └────┬────┘  └────┬────┘  └────┬────┘   │
     │       │            │            │        │
     │       └────────────┼────────────┘        │
     │                    ↓                     │
     │              RabbitMQ                    │
     │                    ↓                     │
     │         ┌─────────────────────┐          │
     │         │   Database Layer    │          │
     │         │ Postgres/Mongo/Fire │          │
     │         └─────────────────────┘          │
     └──────────────────────────────────────────┘

System Components:

Real-Time Service (Node.js)

Handles WebSocket connections, presence, chat, and low-latency signaling

ML Service (Python)

Content recommendations, engagement analytics, automated transcription

Core API (Spring Boot)

User management, course catalog, billing, admin operations

Streaming Gateway

WebRTC signaling, Agora/Wowza integration, recording management

$ man implementation-details

Hybrid Video Streaming Architecture

The platform needed to support multiple streaming scenarios:

Small Groups (2-10 participants): Direct WebRTC peer-to-peer connections for minimal latency Medium Classrooms (10-50): Selective Forwarding Unit (SFU) via Agora.io Large Broadcasts (50+): RTMP to Wowza with HLS delivery

The system automatically selected the optimal path based on participant count and network conditions.

Recording Architecture:

  • Server-side recording for compliance
  • Async transcoding pipeline via RabbitMQ
  • Multi-resolution output (1080p, 720p, 480p)
  • Automatic cleanup after retention period

GKE Deployment Strategy

As a solo engineer, I needed deployments to be reliable and automated:

CI/CD Pipeline (Cloud Build):

  1. Push to main triggers build
  2. Run tests in parallel containers
  3. Build and push Docker images
  4. Deploy to staging GKE cluster
  5. Smoke tests pass → deploy to production
  6. Automatic rollback on failure

GKE Configuration:

  • Horizontal Pod Autoscaling based on CPU/memory
  • Node pools sized for different workload types
  • Preemptible nodes for batch processing (cost savings)
  • Reserved capacity for critical services

This reduced deployment time from hours (manual) to under 10 minutes (automated).

$ echo $RESULTS

Production Platform Delivered Solo

<10min Deploy Time From commit to production
<200ms Stream Latency Interactive video quality
100s Concurrent Users Per classroom capacity
99.5% Uptime Production reliability

Additional Outcomes:

  • Complete platform delivered in 18 months by a single engineer
  • Hybrid streaming architecture handled both small groups and large broadcasts
  • CI/CD automation freed time for feature development
  • Multi-database architecture optimized each data access pattern

$ cat LESSONS_LEARNED.md

Automation Compounds Solo Developer Time

Every hour spent on CI/CD in month 1 saved 10 hours over the project. When you're alone, automation isn't optional — it's survival.

Polyglot Services Are Worth the Complexity

Using Node for real-time, Python for ML, and Java for core logic meant each service was optimal for its purpose. The deployment complexity was manageable with containers.

Documentation Is Future You's Best Friend

As a solo dev, there's no one else to ask. Comprehensive documentation meant I could context-switch between services without losing days.

$ cat README.md

The Solo Backend Challenge

When I joined The Virtulab, they had a frontend team and a product vision, but no backend infrastructure. My job: build everything needed to ship a production virtual classroom platform.

This meant wearing every hat — architect, developer, DevOps, DBA, security engineer. There was no one else to escalate to.

Design Decisions for a Team of One

Why Multi-Language Microservices?

Conventional wisdom says: keep it simple with one language. But I chose polyglot services for a reason: each language excels at different problems.

Node.js for Real-Time:

  • WebSocket connections are I/O bound, not CPU bound
  • The async event loop handles thousands of connections efficiently
  • NPM ecosystem has mature WebRTC and real-time libraries

Python for ML/Data:

  • TensorFlow, scikit-learn, pandas — the ML ecosystem is unmatched
  • Quick prototyping for recommendation features
  • Data processing pipelines are natural in Python

Java/Spring Boot for Core:

  • Type safety catches bugs before production
  • Spring Security handles enterprise auth requirements
  • Performance for CPU-intensive operations

The key insight: containerization makes polyglot manageable. Each service is a Docker image with standardized interfaces. The deployment complexity is handled by Kubernetes, not by me.

Building the Streaming Layer

Real-time video is the hardest part of an EdTech platform. Different scenarios require different approaches:

Peer-to-Peer (WebRTC) For small groups (2-10 people), direct connections minimize latency. I implemented a signaling server in Node.js that coordinated WebRTC handshakes.

Selective Forwarding (Agora.io) Medium-sized classrooms (10-50) needed a middleman to avoid network congestion. Agora’s SFU efficiently forwarded video streams without transcoding.

Broadcast Mode (Wowza) Large lectures (50+) used traditional broadcast architecture. Presenters streamed via RTMP to Wowza, which delivered HLS to viewers.

The platform automatically selected the optimal path based on participant count.

Surviving as a Solo Dev

Some strategies that kept me productive:

Automate Everything Automatable Every manual deploy step became a script. Every script became a CI/CD pipeline. By month 3, I could deploy any service with a git push.

Ruthless Documentation I wrote docs as if explaining to a future teammate. That teammate was future-me, after I’d context-switched away and forgotten the details.

Infrastructure as Code No clicking in GCP console. Everything was Terraform or YAML. This meant I could rebuild the entire infrastructure from scratch if needed.

Monitoring as a First-Class Citizen Cloud Logging, Cloud Trace, and custom dashboards. When something broke at 3 AM, I needed answers fast.

Technical Deep-Dive: CI/CD Pipeline

Here’s the deployment pipeline I built:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# Simplified Cloud Build config
steps:
  - name: 'node'
    entrypoint: 'npm'
    args: ['test']
    
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/$SERVICE_NAME', '.']
    
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/$SERVICE_NAME']
    
  - name: 'gcr.io/cloud-builders/gke-deploy'
    args: ['run', '--filename=k8s/', '--cluster=$CLUSTER_NAME']

The full pipeline included:

  • Parallel test execution
  • Docker layer caching for speed
  • Staging deployment with smoke tests
  • Production deployment with canary rollout
  • Automatic rollback on health check failures

This invested ~40 hours upfront but saved hundreds of hours over the project lifetime.

Key Takeaways

For Solo Engineers

  1. Automation isn’t optional — it’s how you scale yourself
  2. Choose tools that match problems — polyglot is fine if containerized
  3. Document obsessively — you will forget

For Platform Architecture

  1. Hybrid streaming handles all scenarios — don’t force one approach
  2. Event-driven decouples nicely — async processing via queues scales well
  3. Multi-database is often right — PostgreSQL for relational, MongoDB for documents, Redis for ephemeral

For Career Growth

  1. Solo ownership accelerates learning — there’s no hiding from any domain
  2. End-to-end experience is valuable — you understand the full stack
  3. Startups compress experience — 18 months here taught more than 3 years at a large company

Need a solo engineer who can own your backend? Let’s talk.


Experience: Senior Backend Developer at VirtuLab

Technologies: Python, GCP, PostgreSQL, Redis, Docker/Kubernetes

Related Case Studies: Real-time NEMT Dispatch | FinTech Microservices

Building a Real-Time Platform?

Let's discuss how I can help solve your engineering challenges.