System Design & Architecture
Comprehensive system design documentation for the Mr. Mentor platform.
Table of Contents
- System Overview
- High-Level Architecture
- Component Design
- Data Flow
- Scalability Strategy
- Security Architecture
- Communication Protocols
- Technology Choices
System Overview
Mr. Mentor is a mentorship platform connecting students with industry experts through:
- One-on-one video consultations
- Token-based payment system
- Google Calendar integration
- Real-time communication
- Earnings management for mentors
Key Requirements
| Requirement |
Description |
| Availability |
99.9% uptime for video meetings |
| Scalability |
Support 10,000+ concurrent users |
| Performance |
< 200ms API response time |
| Real-time |
Sub-second video call latency |
| Security |
End-to-end encryption for meetings |
| Reliability |
Automatic failover and recovery |
High-Level Architecture
Architecture Diagram
┌─────────────────────────────────────────────────────────────────────┐
│ CLIENT LAYER │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ WEB APP (Next.js) │ │
│ │ React 19 | TypeScript | Tailwind | Socket.io Client │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ MOBILE APP (Future) │ │
│ │ React Native | TypeScript │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────┬────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────┐
│ API GATEWAY / CDN │
│ (Nginx / Cloudflare) │
└────────────────────────────────────┬────────────────────────────────┘
│
┌────────────────────┼────────────────────┐
▼ ▼ ▼
┌───────────────────┐ ┌──────────────┐ ┌─────────────────┐
│ APPLICATION │ │ WEBSOCKET │ │ EXTERNAL │
│ SERVER │ │ SERVER │ │ SERVICES │
│ (Express/Bun) │ │ (Socket.IO) │ │ │
│ REST API │ │ │ │ ┌─────────────┐ │
└───────────────────┘ └──────────────┘ │ │Google OAuth│ │
│ │ │ └─────────────┘ │
│ │ │ ┌─────────────┐ │
┌───────────┴──────────┐ │ │ │Google Calendar│ │
│ │ │ │ └─────────────┘ │
▼ ▼ │ │ ┌─────────────┐ │
┌──────────┐ ┌───────────┐ │ │ │ Razorpay │ │
│ Queue │ │ Workers │ │ │ └─────────────┘ │
│ BullMQ │ │ (Jobs) │ │ │ ┌─────────────┐ │
└──────────┘ └───────────┘ │ │ │ AWS S3 │ │
│ │ │ └─────────────┘ │
│ │ │ ┌─────────────┐ │
▼ │ │ │ Nodemailer │ │
┌──────────────────────────────────┴─────────┤ └─────────────┘ │
│ DATA LAYER │ │
├───────────────────┬────────────────────────┴───────────────────┤
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌────────────┐ ┌──────────────────────────────┐
│PostgreSQL │ │ Redis │ │ MONITORING │
│(Primary DB)│ │(Cache/Queue│ │ - BullBoard │
│ │ │ /Session) │ │ - Health Checks │
│Read Replica│ │ │ │ - Logging │
└─────────────┘ └────────────┘ └──────────────────────────────┘
Component Design
1. Frontend Application (Next.js 15)
Architecture Type
- SSR (Server-Side Rendering) with App Router
- Server Actions for direct database access
- Client Components for interactivity
Key Components
| Component |
Responsibility |
Technology |
| Pages |
Route handlers |
Next.js App Router |
| Layouts |
Page structure |
React Server Components |
| Components |
Reusable UI |
Radix UI + Tailwind |
| Hooks |
State/logic |
Custom React hooks |
| Services |
API communication |
Axios |
| Contexts |
Global state |
React Context |
Component Hierarchy
App (Root Layout)
├── Providers (Auth, User, Socket)
│ ├── LandingPage
│ │ ├── HeroSection
│ │ ├── FeaturesSection
│ │ └── TestimonialsSection
│ ├── ExpertDashboard
│ │ ├── DashboardHeader
│ │ ├── SlotManager
│ │ ├── EarningsOverview
│ │ └── CalendarView
│ ├── Meetings
│ │ ├── MeetingList
│ │ ├── MeetingCard
│ │ └── FilterBar
│ └── MeetingRoom
│ ├── PreJoinScreen
│ ├── VideoGrid
│ ├── ControlsBar
│ └── SidePanel
2. Backend Application (Express.js)
Layered Architecture
┌─────────────────────────────────┐
│ Presentation Layer │
│ (Controllers + Routes) │
└─────────────────────────────────┘
│
▼
┌─────────────────────────────────┐
│ Business Logic Layer │
│ (Services) │
└─────────────────────────────────┘
│
▼
┌─────────────────────────────────┐
│ Data Access Layer │
│ (TypeORM Entities) │
└─────────────────────────────────┘
│
▼
┌─────────────────────────────────┐
│ Database Layer │
│ (PostgreSQL) │
└─────────────────────────────────┘
Core Services
| Service |
Responsibility |
| UserService |
User CRUD, authentication |
| MentorService |
Mentor profiles, availability |
| TokenService |
Token balance, purchases |
| MeetingCompletionService |
Meeting lifecycle, earnings |
| GoogleCalendarService |
Calendar integration |
| EmailService |
Transactional emails |
| S3Service |
File uploads |
| QueueService |
Background job management |
3. Real-Time Communication (Socket.IO + WebRTC)
WebSocket Architecture
Client A Server Client B
│ │ │
├─── join-room ────────>│ │
│ ├─── broadcast ─────────>│
│<── user-joined ────────┤ │
│ │ │
├─── offer (SDP) ───────>│ │
│ ├─── forward offer ─────>│
│ │ │
│ │<── answer (SDP) ───────┤
│<── forward answer ──────┤ │
│ │ │
│<──────── ice-candidate ─┼──────── ice-candidate ─>│
│ │ │
▼ ▼ ▼
Peer Connection Established (P2P)
Signaling Server Flow
- Room Creation: Server creates unique room for each meeting
- User Join: Users join Socket.IO room
- Offer/Answer: SDP exchange through server
- ICE Candidates: Candidate exchange for NAT traversal
- Connection: Direct P2P connection established
4. Database Architecture
Normalization Strategy
- Third Normal Form (3NF) for data integrity
- Denormalization for frequently accessed data (caching)
- Partitioning by date for time-series data
Data Partitioning
meeting_logs (Table)
├── 2024_01 (Partition)
├── 2024_02 (Partition)
├── 2024_03 (Partition)
└── ...
Replication Strategy
┌─────────────┐
│ Primary │
│ (Write) │
└──────┬──────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│Replica │ │Replica │ │Replica │
│(Read) │ │(Read) │ │(Read) │
└────────┘ └────────┘ └────────┘
Data Flow
1. User Registration Flow
Client API Server Database
│ │ │
├─── POST /register ───────>│ │
│ ├─── Validate email ───────>│
│ │<─── Check exists ─────────┤
│ │ │
│ ├─── Hash password │
│ ├─── Create user ──────────>│
│ │<─── User created ─────────┤
│ │ │
│ ├─── Generate JWT │
│ ├─── Send welcome email │
│<─── {user, token} ─────────┤ │
2. Meeting Booking Flow
Client Auth Layer Business Layer Database Cache External
│ │ │ │ │ │
├─── Book slot ──────>│ │ │ │ │
│ │─── Verify token ──>│ │ │ │
│ │<─── User data ─────┤ │ │ │
│ │ │─── Check balance ─>│ │ │
│ │ │<─── Balance ───────┤ │ │
│ │ │ │ │ │
│ │ │─── Check slot ────>│ │ │
│ │ │<─── Available ─────┤ │ │
│ │ │ │ │ │
│ │ │─── Deduct tokens ─>│ │ │
│ │ │─── Update slot ───>│ │ │
│ │ │─── Clear cache ──────────────────>│ │
│ │ │ │ │ │
│ │ │─── Create calendar event ───────────────────────>│
│ │ │ │ │ │
│ │ │─── Queue email ─────────────────────────────────>│
│ │ │ │ │ │
│<─── Success ─────────┴────────────────────┴───────────────────┴─────────────┴──────────────┘
3. Video Call Flow
Student Signaling Server Mentor
│ │ │
├─── join-room ──────────>│ │
│ ├─── notify ────────>│
│ │ │
│<─── user-joined ─────────┤ │
│ │ │
├─── offer (SDP) ─────────>│ │
│ ├─── forward offer ──>│
│ │ │
│ │<─── answer (SDP) ───┤
│<─── forward answer ──────┤ │
│ │ │
│<────── ICE candidates ───┼────── ICE candidates ───>│
│ │ │
▼ ▼ ▼
P2P Connection Established
│ │ │
├─── Audio/Video ──────────────────────────────>│
│<────────── Audio/Video ───────────────────────┤
│ │ │
├─── chat-message ───────>│ │
│ ├─── forward ────────>│
Scalability Strategy
Horizontal Scaling
Application Servers
Load Balancer (Nginx)
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ App 1 │ │ App 2 │ │ App 3 │
│:8000 │ │:8001 │ │:8002 │
└─────────┘ └─────────┘ └─────────┘
Database Scaling
┌─────────────┐
│ Primary │
│ (Master) │
└──────┬──────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│Replica │ │Replica │ │Replica │
│(Slave) │ │(Slave) │ │(Slave) │
└────────┘ └────────┘ └────────┘
Cache Clustering
┌─────────────┐
│ Client │
└──────┬──────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│Redis │ │Redis │ │Redis │
│Master │ │Slave │ │Slave │
└────────┘ └────────┘ └────────┘
Vertical Scaling
- Upgrade Server Specs: More CPU, RAM, SSD
- Database Optimization: Indexing, query optimization
- Connection Pooling: Efficient database connections
- Caching Strategy: Redis for frequently accessed data
CDN Strategy
User → CDN Edge (Static Assets)
│
├─── Images
├─── Videos
├─── JS/CSS
└── Recordings
Security Architecture
Authentication & Authorization
┌─────────────────────────────────────────────────────────┐
│ Authentication │
├─────────────────────────────────────────────────────────┤
│ 1. JWT Token (Access Token) │
│ - 7-day expiration │
│ - Contains: user ID, role, permissions │
│ │
│ 2. Refresh Token (Future) │
│ - 30-day expiration │
│ - Used to obtain new access tokens │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ Authorization │
├─────────────────────────────────────────────────────────┤
│ Role-Based Access Control (RBAC): │
│ - USER: Can book slots, view mentors │
│ - EXPERT: Can create slots, view earnings │
│ - ADMIN: Full system access │
└─────────────────────────────────────────────────────────┘
Data Encryption
| Layer |
Encryption Method |
| Transit |
TLS 1.3 |
| At Rest |
AES-256 |
| Passwords |
bcrypt (cost: 10) |
| JWT |
HMAC-SHA256 |
Security Layers
┌─────────────────────────────────────────────────────────┐
│ Layer 1: Network Security │
│ - Firewall (UFW) │
│ - DDoS Protection (Cloudflare) │
│ - SSL/TLS Termination │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ Layer 2: Application Security │
│ - Rate Limiting │
│ - Input Validation │
│ - SQL Injection Prevention (ORM) │
│ - XSS Protection │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ Layer 3: Authentication & Authorization │
│ - JWT Tokens │
│ - Role-Based Access Control │
│ - Session Management (Redis) │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ Layer 4: Data Security │
│ - Encrypted Database │
│ - Encrypted File Storage (S3) │
│ - Secure Key Management │
└─────────────────────────────────────────────────────────┘
Communication Protocols
1. HTTP/HTTPS (REST API)
Use Cases:
- CRUD operations
- Authentication
- File uploads
- Payment processing
Characteristics:
- Stateful (via JWT)
- Request/Response model
- JSON payload
2. WebSocket (Socket.IO)
Use Cases:
- Real-time meeting signaling
- Chat messages
- Presence updates
- Live notifications
Characteristics:
- Bidirectional
- Persistent connection
- Event-driven
3. WebRTC
Use Cases:
- Video calls
- Audio calls
- Screen sharing
Characteristics:
- Peer-to-peer
- Low latency
- SRTP encryption
Technology Choices
Why Next.js 15?
| Factor |
Decision |
| Performance |
Server-side rendering for fast initial load |
| SEO |
Built-in SEO optimization |
| DX |
Excellent developer experience |
| Ecosystem |
Large community and library support |
| Scalability |
Easy to deploy and scale |
Why Express.js + Bun?
| Factor |
Decision |
| Performance |
Bun is 3x faster than Node.js |
| Simplicity |
Express.js is minimal and flexible |
| Middleware |
Rich middleware ecosystem |
| TypeScript |
First-class TypeScript support |
Why PostgreSQL?
| Factor |
Decision |
| Reliability |
ACID compliance |
| Features |
Full-text search, JSON support |
| Scalability |
Read replicas, partitioning |
| Open Source |
No vendor lock-in |
Why Redis?
| Factor |
Decision |
| Speed |
In-memory operations |
| Versatility |
Cache, queue, session store |
| Persistence |
Optional disk persistence |
| Scalability |
Easy clustering |
Why TypeORM?
| Factor |
Decision |
| TypeScript |
Strongly typed queries |
| ORM Features |
Relations, migrations |
| Active Record |
Easy to use |
| Maintainability |
Clean code structure |
System Constraints & Trade-offs
Constraints
| Constraint |
Impact |
| Budget |
Optimized for cost-effective solutions |
| Timeline |
MVP-focused with iterative improvements |
| Team Size |
Small team, requiring simple architecture |
| Expertise |
Team familiar with JavaScript/TypeScript |
Trade-offs
| Decision |
Benefit |
Trade-off |
| Monolith |
Simple deployment |
Harder to scale independently |
| PostgreSQL |
Feature-rich |
More expensive than MySQL |
| WebRTC |
Low latency |
NAT traversal complexity |
| Redis |
Fast cache |
Additional infrastructure |
| PM2 |
Simple process mgmt |
Limited vs Kubernetes |
Future Improvements
Phase 1: Optimization
- [ ] Implement database query caching
- [ ] Add CDN for static assets
- [ ] Optimize bundle sizes
- [ ] Implement lazy loading
Phase 2: Microservices
- [ ] Split video service
- [ ] Separate payment service
- [ ] Independent notification service
- [ ] Dedicated auth service
Phase 3: Advanced Features
- [ ] AI-powered mentor matching
- [ ] Video recording storage optimization
- [ ] Real-time analytics dashboard
- [ ] Mobile applications (iOS/Android)