Develop Google Meet-like Multiparty Web App

Goal: Build a scalable, Google Meet–like multiparty video conferencing web app.
Backend: Node.js (well-structured, modular)
Frontend: TypeScript + React (you asked for “React v7” — I’ll target React with TypeScript and modern toolchain; note: React versioning in most ecosystems is v18+ — I’ll follow your exact versioning instruction unless you want the latest)
SFU: mediasoup (workers pool, Router per room)
Signaling: socket.io (scalable via Redis adapter)
Payment: Razorpay for tiered plans (free / paid / pro)
Deployment: Docker + Kubernetes (optional), or cloud VM autoscaling; use Redis, Postgres, TURN servers (coturn), and object storage for recordings/screenshots.
A web app that supports:
Multiparty video/audio (grid, active speaker, pin) using mediasoup SFU (low bandwidth on clients).
Screen share, camera toggle, mute/unmute, raise hand, chat (room & private), meeting recording (server-side), meeting links, meeting scheduling, lobby/waiting room, host controls (mute all, remove participant).
Adaptive quality and codec negotiation (VP8/Opus, optional H264).
Authentication (JWT + OAuth option), email invites, join-by-link with room tokens.
Responsive UI (desktop & mobile browsers). Option: PWA packaging.
Billing: Free for up to 100 concurrent users, Paid plan for up to 1000, Pro plan for >1000 with Razorpay checkout and webhooks to enable higher capacity.
Admin dashboard: room metrics, usage, billing, logs.

Scalability:
Mediasoup worker pool & Router per room: run a pool of mediasoup worker processes; assign a Router per room to isolate media mixing and simplify resource allocation.
Dedicated media servers: place mediasoup worker processes on dedicated machines/VMs (or pods) with sufficient CPU and NIC bandwidth. Use node affinity and taints in Kubernetes to dedicate nodes for media.
Signaling layer: scale signaling horizontally (multiple Node.js instances) and use Redis adapter for socket.io to enable cross-instance pub/sub and socket routing.
Distributed state: store ephemeral room/session states in Redis, and persistent metadata (users, rooms, invoices) in Postgres.
Autoscaling thresholds: monitor CPU/memory and concurrent producers/consumers per worker; auto-scale worker counts with a controller (Kubernetes HPA + custom metrics).
Room placement strategy: use room hashing or a placement service to pick the best worker/Router based on current load, geographic proximity, and codec preferences.
Geo-scaling: deploy mediasoup clusters in multiple regions and route clients to the nearest cluster via DNS/geolocation / edge load balancer for latency-sensitive calls.