Revamped Data Infrastructure for State Government Initiatives, Enabling Scalable Data Collection & Reporting

# .NET Development # Angular # AWS Cloud Solutions # AWS Monitoring # AWS RDS # Multi-Tenant
8 min read

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

Emerging Challenges

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)

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.

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

FactorMulti-Tenant (Single Database, Shared Schema)Multi-Tenant (Database Per Tenant)
ArchitectureOne shared database with a state_ID column for segregation.Separate database for each state, with a unified application layer.
Data Privacy & SecurityHigher risk of data leakage between states; complex access control required.Complete data isolation for each state, ensuring privacy and security.
ScalabilityBecomes a bottleneck as data grows, increasing query execution time.Easily scales with additional states without affecting others.
Customization FlexibilityLimited ability to modify workflows per state.Each state can have custom configurations, workflows, and policies.
PerformanceCan suffer from slow queries due to a large dataset.Queries are faster as they operate within state-specific databases.
Data Migration FlexibilityHard to extract state-specific data for migration.Each state’s data can be migrated independently if needed.
Maintenance & OperationsEasier to manage since only one database exists.Requires more effort to manage backups, monitoring, and optimization.
Future-ProofingNot 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:

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.

  1. 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.
  2. 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.
  3. 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.
  4. Centralized Application Layer → The Lighthouse platform maintains one unified codebase for all states, streamlining development, maintenance, and feature rollouts without redundant deployments.
  5. 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

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

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.

Share

Facebook
X.com
LinkedIn

Crafted with by Vivek Amola

© Copyright 2025. All rights Reserved.