Cloud-native multi-tenant SaaS for ed-tech analytics

The trigger

Term-start was a math problem. The existing SaaS analytics platform priced its burst capacity at a 6-figure annual surcharge — payable in advance, used for roughly two windows per year (August district onboarding and January mid-year assessment), idle the rest of the time. The CFO's question was straightforward: are we paying $200K/year to handle 8 weeks of traffic?

The other half of the trigger was integration pain. Each new district required a 4-6 week custom integration to ingest their LMS assessment data. The analyst team had built a manual normalization pipeline in Excel macros — impressive engineering, but unmaintainable as district count grew. The platform was on track to onboard 24 new districts in the coming year; that math was untenable.

The third pressure was standards. The state department of education had quietly published a roadmap requiring LTI 1.3 + QTI 3.0 compliance for any provider claiming "interoperability" in their procurement materials. The existing platform was LTI 1.1 — out of compliance within 18 months. Either rebuild for compliance or get cut from procurement shortlists.

The week-one discovery

Week zero we mapped the actual data flows. The platform handled 12 districts, each with 2-7 LMS partners (Canvas, Schoology, PowerSchool, Brightspace, Moodle, two custom regional LMSes). That's roughly 40 distinct inbound formats. Some were clean (Canvas's LTI 1.3 endpoint was well-formed). Some were file drops via SFTP at 3am every night. One was a daily email with a CSV attachment.

The 7 different inbound file formats clustered into 4 actual data shapes underneath the format variation. The Excel macros had been doing the cluster-and-normalize work for years; we found a 4,200-line workbook with VBA that, once we deciphered it, was effectively a hand-rolled ETL engine. The analyst who built it had moved on 18 months earlier. Nobody on the current team understood it.

The standards-compliance work was a moving target. LTI 1.3 had stabilized but QTI 3.0 was still in IMS Global's "experimental" phase — meaning the spec was published but reference implementations had been changing month-to-month. CASE 1.1 was stable but only two of the 12 districts had vendors emitting CASE-formatted data; the rest would need translation layers.

The hardest discovery: 4 of the 12 target districts had hard requirements that were mutually incompatible. District A required ALL student data to never leave their AWS region. District B required all data to flow through their on-premises ETL appliance before reaching cloud. District C required full PII isolation between tenants AND prohibited any vendor-side aggregation across districts. We documented these in week 0 because they shaped the architecture.

The architecture decisions

**.NET Core vs team-preferred Python.** The client's existing engineering team was .NET-strong. The maintenance hand-off mattered more than our team's productivity. .NET Core (now .NET 8) gave us battle-tested microservices ergonomics and the team can fork into the codebase post-handoff without retraining. The decision is documented in the architecture memo so future architects understand why.

**Microservices vs monolith.** Burst capacity was the deciding factor. A monolith would have required scaling the whole application at term-start; microservices let us scale the ingestion pipeline separately from the dashboard rendering. We accepted the operational complexity (5 services instead of 1) because the alternative — paying $200K/year for SaaS burst capacity — was the problem we were solving.

**RabbitMQ vs Kafka.** The team had RabbitMQ in their stack already (used elsewhere in their Microsoft-shop architecture). Kafka would have been technically defensible for the scale targets but added a new operational discipline the team would have to maintain. RabbitMQ was the right boring choice. We documented the upgrade path to Kafka in the architecture memo for the day they outgrow RabbitMQ (somewhere north of 50× current throughput).

**Synapse vs Snowflake.** The client had an Azure commitment. Synapse Analytics integrates natively with their existing Azure tenant, their existing Active Directory groups for access control, and their existing Power BI Embedded licenses. Snowflake would have been faster on some query patterns but the operational integration cost would have eaten the speed advantage at their scale.

**Power BI Embedded vs custom React dashboards.** Power BI Embedded won on time-to-ship and on the licensing economics (the client already had E5 licenses). Custom React would have given us more design control but the lift to match Power BI's standard chart library (sortable tables, drill-down on cohort comparisons, scheduled email reports) would have eaten 3 weeks. We did the design work on the Power BI side to push the dashboards as far as the platform allows.

The build

Weeks 2-7 ran on a build-test-deploy loop with mock LMS data for every district shape. We assembled a "district simulator" that could emit any of the 7 inbound formats at configurable rates — invaluable for stress-testing the ingestion pipeline before any real district was connected.

Week 5 surprise: a QTI 3.0 experimental endpoint at one of the target districts changed mid-build. The IMS Global working group had published a minor revision and one LMS vendor had pushed it to production overnight. Our ingestion was hitting field names that no longer existed. We shipped version detection in the QTI adapter — sniff the response, route to the right parser variant — in 6 hours. The fix went in week 5; in retrospect it should have been in week 1.

Week 7 was load-testing. We hit the platform with district-simulator traffic at 80× baseline (matching the worst-case term-start spike). The dashboard rendering held; the autoscale fired as designed; one query in the Synapse warehouse took 9 seconds and broke our latency budget. We rewrote it as a materialized view in 3 hours. The day a real district uploaded a 1.2GB assessment dump as their "we want to test the platform too" trial — and the pipeline handled it in 4 minutes — the team knew the architecture was sound.

Multi-tenant isolation testing was painstaking. We ran adversarial test cases: tenant A's JWT trying to access tenant B's data, tenant A's BI query attempting cross-tenant aggregation, tenant A's user filling Power BI report URL with tenant B's report ID. All blocked at the API layer; all logged in the audit trail.

The cutover

Phased onboarding: 1 district in week 9 (the simplest data shape — Canvas LTI 1.3 only), 4 districts by week 10 (mixed shapes including SFTP file drops), all 12 districts by week 14 (post-handoff). The first district's analyst lead said the onboarding took 90 minutes — most of it was scheduling, not technical work. They had been bracing for 4-6 weeks per the old playbook.

Term-start traffic spike hit week 16, two weeks after the last district was live. Autoscale fired across the ingestion microservices as designed. Peak load was 87× baseline (we'd designed for 80×, the autoscale headroom absorbed the rest). Dashboard rendering stayed under 2-second p95 latency throughout the spike. The CFO's $200K SaaS burst-invoice never came.

Ninety days later

The 80× burst-handled metric is the headline, but the better metric is the one we didn't expect: district onboarding now takes 2 days, not 6 weeks. The analyst team has run 8 new district onboardings since handoff using the runbook we left them. Each onboarding is now mostly configuration (mapping the district's LMS endpoints to our adapters) instead of custom integration work.

Standards-compliance review with the state DOE happened in Q4. LTI 1.3, QTI 3.0, and CASE 1.1 all certified. The platform stayed on procurement shortlists.

The Excel-macro engine has been decommissioned. The analyst whose VBA we'd been reverse-engineering would probably be glad to know it's been retired with honors — it shipped the company for 5 years before a proper platform was viable.

What we'd do differently

The week-5 QTI-version-change surprise was avoidable. We should have negotiated direct access to all 7 LMS partners' standards-test environments in week zero, not built against the cached schema. Spec drift in experimental standards is the norm, not the exception. Next standards-implementation engagement starts with a week-zero "subscribe to the spec working group" item.

The district-simulator was the best testing investment of the engagement. We'd build it earlier — week 1 not week 3 — on any future multi-tenant platform engagement. Adversarial test data beats production data for finding architectural issues.

We'd build the standards-version-detection layer up-front, not as a week-5 hotfix. The pattern (sniff the response, route to the right parser variant) is reusable across any experimental-standards endpoint.