School System Backend Optimization

Optimize project backend architecture to reliably support 1.5–2 lakh active users with low latency, controlled cloud costs, and predictable scaling, without rewriting the entire system.

This tells the engineer:
• Performance > fancy tech
• No rebuild madness
• Practical results expected

⸻

Current Tech Stack (must be explicit)

Frontend
• React (web)

Backend / Infra
• Firebase Firestore
• Firebase Auth
• Firebase Cloud Functions
• Firebase Storage (if any)

Expected Add-on (optional, NOT mandatory)
• PostgreSQL (Supabase / Cloud SQL) — only if justified

Snowflake, Kafka, Hadoop NOT required at this stage.

⸻

Scale Assumptions (anchor the design)

Engineer must assume:
• 2-2.5 lakh total users
• 40–60k daily active users
• High read/write operations during school hours
• Multiple schools, each with:
• Students
• Teachers
• Batches
• Attendance
• Exams
• Fees

This avoids under-engineering.

⸻

Scope of Work (ANALYZE → DESIGN → IMPLEMENT)

Phase 1: System & Data Audit (Mandatory)

Engineer must:
• Review Firestore collections & document structure
• Identify:
• Heavy read queries
• Large documents
• Deep nesting
• Missing / wrong indexes
• Costly real-time listeners
• Map read/write hotspots
• Identify scaling bottlenecks
• Estimate cost impact of current design

Output:
• List of issues (with severity)
• Explanation of why they are problems

⸻

Phase 2: Query & Data Structure Optimization

Engineer must:
• Redesign Firestore collections for:
• Shallow documents
• Batch-wise & time-based access
• Introduce:
• Pagination
• Time-bucketed collections (monthly / yearly)
• Batch writes where applicable
• Ensure queries:
• Avoid full-collection scans
• Avoid student-centric large joins
• Suggest composite indexes where required

Goal:
• Reduce read counts
• Improve latency
• Keep Firebase bills predictable

⸻

Phase 3: Hot / Warm / Cold Data Separation

Engineer must:
• Define:
• Hot data (daily operations)
• Warm data (recent history)
• Cold data (archive / analytics)
• Decide:
• What stays in Firestore
• What should move to SQL / archive
• Propose data archival strategy (quarterly/yearly)

SQL introduction ONLY if:
• It clearly reduces cost
• It improves performance
• Firebase alone is insufficient

⸻

Phase 4: Implementation & Fixes (Critical)

Engineer must:
• Implement approved optimizations
• Modify existing queries
• Add indexes
• Refactor critical paths
• Optimize Cloud Functions (if used)
• Ensure no breaking changes for users

This is NOT advisory only — execution is required.

⸻

Performance & Scale Expectations (non-negotiable)

After optimization, system should:
• Handle 1.5 lakh users comfortably
• Target 2 lakh users where feasible
• Maintain:
• Consistent response times
• Stable Firebase costs
• Avoid performance degradation during peak hours

Engineer must explain:
• Expected limits
• Bottlenecks beyond which new infra is needed

⸻

Cost Awareness

Engineer must:
• Justify every new service
• Estimate:
• Firebase read/write reduction
• Monthly infra cost at scale
• Prefer:
• Minimal services
• Simpler architecture
• Avoid:
• Overengineering
• Premature data warehouses

⸻

Deliverables

Mandatory Deliverables:
1. Optimized data schema (diagram or doc)
2. Query guidelines (do’s & don’ts)
3. Implemented changes in codebase
4. Cost impact explanation
5. Scaling roadmap (50k → 2 lakh users)

⸻

Engagement Model (budget-safe)
• Duration: 3–4 weeks
• Commitment: Part-time
• Budget: ₹30k–₹45k fixed
• Payment milestone-based:
• Audit complete
• Optimizations implemented
• Final review

⸻

What We Explicitly Do NOT Want
• Full backend rewrite
• Heavy big-data tools
• Complex microservices
• Long-term dependency