My Role
Engineering Manager
Project Year
2023 - 2024
Project Duration
10 Months
Challenges Addressed
Scalability bottlenecks in the tech platform led to high infrastructure costs, fragmented data management, inefficient state-wise deployments, and slow onboarding.
Key Outcome
Transition to a multi-tenant (database-per-tenant) architecture, reducing operational costs by 50%, improving state-wise data isolation, enabling faster feature rollouts, and streamlining new state onboarding with minimal effort.
Client Background
One of the leading Indian non-profits, deeply involved in supporting the Samagra Shiksha initiative launched by the Indian Government, aims to provide holistic education from pre-primary to senior secondary levels, emphasizing the integration of vocational education into mainstream curricula through technology-driven solutions.
The Vocational Education Departments of Maharashtra, Odisha, Jharkhand, and Gujarat have been working closely with the non-profit to leverage their human resources, motivated domain experts, and technology implementation for data collection, visualization, and analysis from the ground.
Project Overview
As the initiative scaled, Lighthouse
, the technology platform, became essential for state-wise data collection, capturing student attendance, trainer sessions, field visits, guest lectures, and industrial training data. This data served as the foundation for real-time visualization, performance tracking, and reporting, ensuring measurable outcomes, transparency, and strategic decision-making—critical for both the government and the non-profit’s vision.
Initially, technology adoption was incremental, driven by feedback from states, schools, and trainers. However, the fragmented infrastructure proved inefficient and unsustainable. While Maharashtra, Odisha, Jharkhand, and Gujarat had been operational for four years, expansion and collaboration with to Vocational Education Departments of Delhi, Uttar Pradesh, Andhra Pradesh, Rajasthan, and Chhattisgarh exposed scalability bottlenecks.
As Engineering Manager, I spearheaded the migration from a single-tenant to a multi-tenant architecture, optimizing scalability, cost efficiency, and streamlined state management.
Challenges & Requirements
As more states adopted Lighthouse, the initial single-tenant setup became difficult to scale, maintain, and optimize. While designed to meet state-specific needs, it introduced operational inefficiencies over time.
Why the Single-Tenant Approach Was Initially Adopted
- State-Specific Customization → Each state had unique workflows and reporting requirements, requiring independent modifications.
- Independent Data Control → Governments preferred full ownership of their data, with the flexibility to migrate it to their own infrastructure in the future.
- Strict Data Isolation → Ensured compliance with privacy policies, preventing cross-state data access.
- Phased Adoption → States onboarded at different times, making separate deployments practical in the early stages.

Emerging Challenges
- Multiple Codebases → Redundant development efforts due to separate Lighthouse instances for each state.
- Difficult Maintenance → Bug fixes and updates had to be implemented individually, increasing complexity.
- Scalability Issues → With millions of student records, managing performance and expansion became challenging.
- High Infrastructure Costs → Maintaining separate AWS EC2 servers and databases for each state led to rising operational expenses.
Single-Tenant Architecture (Initial Approach)
A state-specific deployment model, the single-tenant architecture provided customization and data isolation but led to redundant infrastructure, high maintenance overhead, and scalability challenges as more states onboarded.
How It Worked (Technology Stack & Workflow)
- Frontend: Built on Angular, providing state-specific interfaces for logging student attendance, training sessions, and field activities.
- Mobile App: Developed using Ionic Framework, allowing only trainers to record on-the-go attendance, session details, and field visits.
- Backend: Built on .NET Framework, each state had an independent Lighthouse instance with custom workflows.
- Database: Dedicated SQL databases per state ensured data isolation and future migration flexibility.
- Infrastructure: Hosted on AWS EC2, requiring separate compute and storage per state, increasing maintenance efforts.
- Reporting & Analytics: Microsoft Power BI powered state-level insights on student engagement and program effectiveness.

This setup addressed initial customization and data sovereignty needs but proved inefficient for scalability and centralized management.
Solution: Transition to a Multi-Tenant Architecture
To address scalability, maintainability, and cost efficiency, we redesigned Lighthouse using a Multi-Tenant Architecture, ensuring a single, unified platform that could accommodate multiple states while maintaining data privacy and operational flexibility. The transition aimed to simplify deployments, streamline development efforts, reduce infrastructure costs, and improve overall system performance.

- One Codebase for All States → Streamlined development, allowing faster feature rollouts, centralized bug fixes, and reduced redundancy.
- State-Specific Data Segregation → Ensured strict data isolation, meeting government privacy and compliance requirements while maintaining operational flexibility.
- Optimized Infrastructure Costs → Transitioned from multiple AWS EC2 instances to a more scalable, cost-effective RDS-based architecture, significantly reducing server expenses.
- Seamless Onboarding for New States → Enabled rapid deployment by eliminating the need for independent state-specific setups.
Exploring Multi-Tenant Approaches
To achieve this transformation, we analyzed two architectural models, each with its own advantages and trade-offs in terms of scalability, performance, data privacy, and operational complexity.
Multi-Tenant (Single Database, Shared Schema)
In this model, a single database would store data for all states, with a state_ID
column used to segregate records.

Multi-Tenant (Database Per Tenant)
In this approach, each state had a dedicated database, while the application code remained unified. The system dynamically routed requests to the appropriate state database based on tenant configuration.

Comparing Multi-Tenant Approaches
Factor | Multi-Tenant (Single Database, Shared Schema) | Multi-Tenant (Database Per Tenant) |
---|---|---|
Architecture | One shared database with a state_ID column for segregation. | Separate database for each state, with a unified application layer. |
Data Privacy & Security | Higher risk of data leakage between states; complex access control required. | Complete data isolation for each state, ensuring privacy and security. |
Scalability | Becomes a bottleneck as data grows, increasing query execution time. | Easily scales with additional states without affecting others. |
Customization Flexibility | Limited ability to modify workflows per state. | Each state can have custom configurations, workflows, and policies. |
Performance | Can suffer from slow queries due to a large dataset. | Queries are faster as they operate within state-specific databases. |
Data Migration Flexibility | Hard to extract state-specific data for migration. | Each state’s data can be migrated independently if needed. |
Maintenance & Operations | Easier to manage since only one database exists. | Requires more effort to manage backups, monitoring, and optimization. |
Future-Proofing | Not ideal for long-term scaling as states demand more control over data. | Future-ready, allowing states to take ownership of their data when needed. |
Final Decision: Multi-Tenant (Database Per Tenant)
After evaluating security
, scalability
, and operational feasibility
, we implemented the Multi-Tenant (Database Per Tenant) model. This architecture provided the best balance of data privacy, scalability, and flexibility, ensuring that:
- State-specific data governance policies were met.
- Infrastructure remained scalable, avoiding a single point of failure.
- Performance was optimized, even as more states onboarded.
- Future state-specific migrations could be handled smoothly.
Multi-Tenant Lighthouse Ecosystem – Architecture Overview
The multi-tenant architecture implemented for the Lighthouse platform, enabling seamless state-wise operations while maintaining data isolation, scalability, and centralized management. This architecture ensures that each state functions independently while sharing a unified application layer for efficient program execution and reporting.

- State-Specific Access & Operations → Each state’s staff (e.g., Delhi, Rajasthan, Chhattisgarh, Uttar Pradesh, Andhra Pradesh) accesses the Lighthouse platform through the same web application, ensuring a consistent experience across all states.
- API Gateway for Multi-Tenant Identification → When a user logs in, the API Gateway identifies the respective state using a
tenant identifier
, directing requests to the correct database. - Database Routing & Isolation → Based on the tenant identifier, the system dynamically connects to the appropriate database (e.g., Delhi Database, Uttar Pradesh Database, etc.) stored on AWS RDS. This ensures strict data separation, preventing cross-state data access.
- Centralized Application Layer → The Lighthouse platform maintains one unified codebase for all states, streamlining development, maintenance, and feature rollouts without redundant deployments.
- Scalable Multi-Tenant Infrastructure → As more states onboard, additional tenant databases can be seamlessly added without disrupting the existing system, making it scalable, cost-efficient, and easy to maintain.
By implementing this multi-tenant architecture, Lighthouse became a future-ready, scalable, and secure platform, capable of handling multi-state vocational education programs with minimal infrastructure complexity.
Key Achievements
- 50% Reduction in Operational Costs → With the multi-tenant model, adding a new state now only requires tenant setup, significantly reducing time, cost, and infrastructure overhead.
- Performance Optimization → Upgraded to .NET latest framework and Angular for faster response times.
- Faster Bug Fixes & Feature Rollouts → Single codebase enables simultaneous updates for all states.
- Reduction in Infrastructure Costs → Moving from EC2-based hosting to AWS RDS multi-tenant databases.
- Seamless Onboarding of New States → New state setup is now automated and efficient.
- Data Privacy & Compliance → Each state’s database is isolated, meeting government security requirements.
Role & Impact
As the Engineering Manager
, I led the transition from a single-tenant to a multi-tenant architecture, ensuring scalability, efficiency, and cost reduction while maintaining state-wise data isolation and compliance. I collaborated with state government officials, technology teams, and stakeholders to design a future-ready infrastructure for Lighthouse.
Key Skills Demonstrated
- Multi-Tenant System Architecture (Database-Per-Tenant Model)
- Cloud Infrastructure Management (AWS RDS, EC2, Cost Optimization)
- Backend & Frontend Optimization (.NET, Angular, Performance Tuning)
- Data Security & Compliance (State-Wise Data Isolation, Governance)
- Scalability & Performance Engineering (Query Optimization, Load Handling)
- Database Management & Query Optimization (Efficient Data Processing)
- Team Management & Leadership (Engineering, DevOps, Cross-Functional Collaboration)
- Stakeholder & Technical Communication (Govt Officials, Developers, Policy Alignment)
- Project & Change Management (Seamless Transition, Risk Mitigation)
- Feature Rollout & Deployment Strategy (CI/CD, Release Management)
This strategic transformation has positioned Lighthouse as a scalable, efficient, and future-ready vocational education platform, capable of handling multi-state deployments with minimal operational overhead.