Multi-Tenancy Support in the Ed-Fi Tech Stack

Owned by Vinaya Mayya
Mar 20, 2024
4 min read

Definitions of Terms

Ed-Fi customers often ask about multi-tenancy support in the Ed-Fi Tech Stack. Answering this gets messy because of the many different definitions of "multi-tenancy." If we can agree that "multi-tenant" means "multiple customers share system resources," then any two architects may disagree about the applicable system boundaries. Is a system "multi-tenant" if all customers (potentially) pass through the same web server, but then branch out to separate databases?

Before looking at the patterns that can be implemented using Ed-Fi technology, let us define a few terms in the scope of this document:

  • Tenant: a customer, typically a Local Education Agency (LEA), though a State Education Agency (SEA) can also be considered as a tenant/customer, when implementing Ed-Fi for state accountability use cases.
  • Multi-Tenant: some or all of the system can process data for multiple tenants (customers) through the same resource(s).
  • Nested Tenancy:  a technical service provider using a multi-tenant pattern, one of whose tenants is an administrative service provider that is further serving multiple tenants through shared web and/or database resources.
  • Environment: segregated implementations with potentially different security settings and and versions of software. Some examples include: production, sandbox, UAT, test, etc. This term is ultimately orthogonal to the discussion of tenancy-support. It is defined here to avoid accidentally using the word "environment" to refer to a tenancy pattern.
  • API Database Access Strategies: a single ODS / API instance can manage databases (Admin, ODS, Security) using multiple strategies:
    • Shared - the web application accesses only one of each database (Admin, ODS, Security)
    • Year-Specific - the web application accesses a single set of (Admin, Security) and multiple ODS databases, with the year in the database name
    • District-Specific - the web application accesses a single set of (Admin, Security) and multiple ODS databases, with an LEA/district name in the database name
    • District-Year Specific - combines aspects of both the year-specific and district-specific databases. Tentatively for release with ODS/API for Suite 3, version 5.1.0.

Shared-Everything

Single Ed-Fi ODS/API installation running in “Shared Instance” or “Year Specific” mode with one or more “tenant” organizations (ex: an LEA) using the same logical* web server, API instance, database server, and database catalogs (* could be running in a clustered mode).

This is the typical meaning of multi-tenancy, as seen in this definition from IBM:

"Multi-tenant software architecture, which enables multiple users to share a single instance of a software application and its underlying resources, is the foundation of most SaaS offerings."

Education Agency Business Process Security Considerations contains the following warning:

In the as-shipped Ed-Fi ODS / API, any API client (e.g., a district student information system) with permissions to write to student enrollment records (API resource /studentSchoolAssociation) can claim enrollment of a student. Once a district client system claims this enrollment, it can read the core student record, which can include a variety of demographic and contact data.

This multi-tenancy pattern heightens the impact of this risk if vendor credentials are not configured correctly, or if a vendor who supports multiple tenants accidentally connects with the wrong credentials.

Segregated Databases

An alternative pattern for multi-tenancy is to use a shared web server / API instance, while placing each tenant on a separate ODS database. ODS/API for Suite 3 version 5.0.0 introduced the "district specific" mode with separate ODS databases for each tenant. 

Upcoming releases will introduce  "instance-year" combination mode, which adds further segregation of the Admin and Security databases ("district" becoming "instance" to be more generic): ODS-4332 - Getting issue details... STATUS , EDFI-386 - Getting issue details... STATUS

Shared Servers, Separate Applications

In this pattern, the application instances and databases are fully segregated; although located on the same servers, there is no mingling of client data at the software level. Note that any of the four deployment modes can be used here. Naturally this pattern has variations such as a single web server and multiple databases servers, as well as use of cloud managed services.

Contents