Start with E — per-school silos + control plane

• One database per school — own schema, own credentials, own backup line. A connection to school A physically cannot read school B.Isolation is structural, not a WHERE clause.
• Control plane — auth, school registry (catalog), routing, feature flags. Small, boring, its own database.
• One shared app fleet — the same NestJS pods serve every school; the verified identity plus the validated X-School-Id header decide which school database the request touches.

Add F's aggregation gate later

• Trigger to build it: the first real need for cross-school insight (benchmarks, platform dashboards, per-feature usage).
• Aggregates only, one way — a scheduled job computes school-level aggregates (counts, averages) into a separate analytics store. No row-level data ever leaves a silo.
• Governance built in: minimum cohort size (e.g. suppress any aggregate covering < 5 schools), audit log of every aggregate query, no ad-hoc row egress path.

• After login, if memberships.length > 1 the UI routes to /choose-school — a card per school (name, logo, the user's role there).
• Selection sets the active school: saved as last-choice via POST /me/active-school, and from then on every request carries X-School-Id with that value — which the server membership-checks each time.
• Only then does the app fetch dashboard data. There is no "no school selected" state after this point.
• A school switcher stays in the top-nav; switching changes the header value and fully reloads dashboard state (no data from school A ever remains mounted while school B is active). A wrong or stale header value can't leak anything — the per-request check 403s it.

• Remember the last choice per user (control plane), preselect it — but still show the picker on first login of the day for multi-school users.Fast for the 95% case, explicit for auditability.
• Roles are per membership — the same person can be school_admin at school A and plain teacher at school B. The token carries the role of the active school only.
• Deep links: a link opened while the "wrong" school is active shows a one-click "Switch to DPS Pune to view this" interstitial — never silently switches.

src/
├── auth/            # JWKS verify of external IdP token
│   ├── idp-jwt.strategy.ts   # issuer + audience checks
│   └── roles.guard.ts        # @Roles(...) — role from OUR memberships
├── tenancy/
│   ├── tenant.middleware.ts  # JWT → school_id → connection
│   ├── catalog.service.ts    # control-plane lookup (cached)
│   └── connection.manager.ts # pool per school, LRU-capped
├── control-plane/   # schools registry, memberships,
│   │                #   feature flags, audit log
├── students/        # feature modules — all tenant-scoped
├── teachers/
├── analytics/       # later: F's aggregation gate
└── common/          # validation pipes, rate limits, filters

// tenant.guard.ts
const { sub } = await verifyIdpJwt(req);   // JWKS of the external auth service
const schoolId = req.headers['x-school-id'];
const member = await this.memberships
    .check(sub, schoolId);                 // control plane, cached 60 s
if (!member) throw new ForbiddenException();
req.tenant = { schoolId, role: member.role,
  conn: await this.connections.forSchool(schoolId) };

// connection.manager.ts
async forSchool(id: string) {
  if (this.pools.has(id)) return this.pools.get(id);
  const cfg = await this.catalog.dbConfig(id);
  //   ↑ host + creds from Secrets Manager, cached 5 min
  const pool = createPool({ ...cfg, max: 5 });
  this.pools.set(id, pool);       // LRU-evict past ~200
  return pool;
}

• Small pools × many schools — 5 conns/school; PgBouncer in front once schools × pools approaches Postgres limits.
• Migrations for all silos — one command loops the catalog and applies migrations per school; a new school gets them at onboarding.

rule "expire-hourly" { prefix = "hourly/"  expiration { days = 10 } }
rule "expire-daily"  { prefix = "daily/"   expiration { days = 30 } }
rule "monthly-cold"  { prefix = "monthly/"
  transition { days = 60  storage_class = "GLACIER_IR" }
  expiration { days = 365 } }

• Per-school files — restoring school #42 never touches the other silos (the whole point of option E).
• Backup monitoring: the CronJob writes a success marker per school; a daily check alerts on any school with no fresh backup — silent backup failure is the classic DR killer.
• Restore drills: monthly, restore one random school's dump into a scratch instance and run a row-count sanity check. A backup that was never restored is a hope, not a backup.

school_features
  school_id      "sch_dps_pune"
  feature_key    "analytics" | "attendance"
                 | "fee_module" | "parent_portal"
  enabled        true
  source         "plan" | "school_admin" | "platform"
  updated_by / updated_at        # audited

• API: a FeatureGuard (@Feature('fee_module')) returns 404 when off — features that are off don't exist, they aren't just hidden.
• UI reads GET /me/features once per session; flags cached 60 s server-side.
• Plan defines the ceiling; school admins toggle freely below it; you override anything from the platform panel.

• Terraform owns all infrastructure — VPC, EKS, RDS, S3 lifecycle, WAF, Route 53. State in S3 with DynamoDB locking; the AWS console is read-only.
• Kubernetes manifests (Helm) live in the same repo — reviewed and versioned like any code.
• School onboarding is a pipeline job, not a checklist: create DB + user + secret, run migrations, insert the catalog row.
• Same modules for production, sandbox and the DR region — only tfvars differ. This is what makes the §8 runbook a variable change, not a rebuild-from-memory.

• Two cloud environments only. Local dev is docker-compose on the laptop — free, and not a deployed environment.
• sandbox — prod-shaped but scaled down: single-AZ RDS, spot nodes, two demo schools. Auto-deployed on every merge; also where restore drills and demos run.
• production — multi-AZ everything; changes arrive only through the pipeline's manual gate.
• DR — no standing environment: code (git) + replicated images (ECR) + replicated backups (S3) are the whole system, so standing cost is near zero.

• Database-per-school ≠ instance-per-school — many silo databases share one RDS instance while keeping option E's isolation (separate DB + separate credentials). Promote heavy schools to their own instance only when they earn it.
• Savings Plans / reserved instances once load is steady — 30–40% off EC2 + RDS.
• Graviton (t4g / m6g / r6g) — already assumed in the table, ~20% cheaper than x86.
• Spot nodes for sandbox and the backup CronJobs.
• VPC endpoints for S3 / ECR — cuts NAT data-processing charges.
• The §7 lifecycle rules are a cost control too — hourlies die at 10 days, Glacier after 60.

• AWS Budgets — alerts at 80% and 100% of the monthly target; anomaly detection on.
• Cost-allocation tags on everything (env, school_id where possible) — Cost Explorer then shows cost per school.
• Weekly cost review is part of ops, like uptime — the per-school number is the one to watch: it should keep falling as schools grow.

सुरुवात E ने — प्रत्येक शाळेचा silo + control plane

• प्रत्येक शाळेसाठी स्वतंत्र डेटाबेस — स्वतःचा schema, स्वतःची credentials, स्वतःची बॅकअप लाईन. शाळा A च्या connection ला शाळा B चा डेटा वाचणे शक्यच नाही.Isolation रचनेतच आहे — WHERE clause मध्ये नाही.
• Control plane — auth, शाळांची नोंदवही (catalog), routing, feature flags. छोटे, साधे, स्वतःच्या डेटाबेससह.
• एकच shared app fleet — तेच NestJS pods सर्व शाळांना सेवा देतात; पडताळलेली ओळख + तपासलेला X-School-Id header ठरवतो कोणत्या शाळेच्या डेटाबेसकडे जायचे.

F चे aggregation gate नंतर जोडा

• कधी बांधायचे: cross-school माहितीची पहिली खरी गरज (benchmarks, प्लॅटफॉर्म dashboards, feature-वापराचे आकडे).
• फक्त aggregates, एकाच दिशेने — scheduled job शाळा-पातळीवरील aggregates (संख्या, सरासरी) वेगळ्या analytics store मध्ये मोजतो. Row-level डेटा silo बाहेर कधीच जात नाही.
• Governance अंगभूत: किमान cohort आकार (उदा. ५ पेक्षा कमी शाळांचा aggregate दडपणे), प्रत्येक aggregate query चा audit log, ad-hoc row egress मार्ग नाही.

• लॉगिननंतर memberships.length > 1 असल्यास UI /choose-school वर नेते — प्रत्येक शाळेचे कार्ड (नाव, लोगो, तिथली role).
• निवड सक्रिय शाळा ठरवते: POST /me/active-school ने शेवटची-निवड जतन होते, आणि पुढील प्रत्येक request त्या मूल्यासह X-School-Id पाठवते — जी server दर वेळी membership-तपासतो.
• त्यानंतरच app dashboard चा डेटा आणते. या बिंदूनंतर "शाळा निवडलेली नाही" अशी स्थितीच उरत नाही.
• Top-nav मध्ये शाळा बदलण्याचा switcher असतो; बदल header चे मूल्य बदलतो आणि dashboard पूर्ण reload होते (शाळा B सक्रिय असताना शाळा A चा कोणताही डेटा स्क्रीनवर उरत नाही). चुकीचे/शिळे header मूल्य काहीही leak करू शकत नाही — प्रत्येक request ची तपासणी त्याला 403 देते.

• शेवटची निवड लक्षात ठेवा (control plane मध्ये), ती preselect करा — पण multi-school युजरना दिवसाच्या पहिल्या लॉगिनला picker दाखवाच.९५% वेळा जलद, audit साठी स्पष्ट.
• Roles प्रत्येक membership नुसार — तीच व्यक्ती शाळा A त school_admin आणि शाळा B त फक्त teacher असू शकते. Token फक्त सक्रिय शाळेची role वाहतो.
• Deep links: "चुकीची" शाळा सक्रिय असताना उघडलेली लिंक "हे पाहण्यासाठी DPS पुणे वर स्विच करा" असे एक-क्लिक interstitial दाखवते — कधीही आपोआप स्विच होत नाही.

src/
├── auth/            # JWKS verify of external IdP token
│   ├── idp-jwt.strategy.ts   # issuer + audience checks
│   └── roles.guard.ts        # @Roles(...) — role from OUR memberships
├── tenancy/
│   ├── tenant.middleware.ts  # JWT → school_id → connection
│   ├── catalog.service.ts    # control-plane lookup (cached)
│   └── connection.manager.ts # pool per school, LRU-capped
├── control-plane/   # schools registry, memberships,
│   │                #   feature flags, audit log
├── students/        # feature modules — all tenant-scoped
├── teachers/
├── analytics/       # later: F's aggregation gate
└── common/          # validation pipes, rate limits, filters

// tenant.guard.ts
const { sub } = await verifyIdpJwt(req);   // बाहेरील auth service चे JWKS
const schoolId = req.headers['x-school-id'];
const member = await this.memberships
    .check(sub, schoolId);                 // control plane, ६० से cache
if (!member) throw new ForbiddenException();
req.tenant = { schoolId, role: member.role,
  conn: await this.connections.forSchool(schoolId) };

// connection.manager.ts
async forSchool(id: string) {
  if (this.pools.has(id)) return this.pools.get(id);
  const cfg = await this.catalog.dbConfig(id);
  //   ↑ host + creds — Secrets Manager, ५ मि cache
  const pool = createPool({ ...cfg, max: 5 });
  this.pools.set(id, pool);       // ~200 नंतर LRU-evict
  return pool;
}

• छोटे pools × अनेक शाळा — प्रति शाळा ५ connections; schools × pools Postgres च्या मर्यादेजवळ आल्यावर समोर PgBouncer.
• सर्व silos साठी migrations — एकच command catalog फिरून प्रत्येक शाळेवर migrations चालवते; नवीन शाळेला त्या onboarding च्या वेळीच मिळतात.

rule "expire-hourly" { prefix = "hourly/"  expiration { days = 10 } }
rule "expire-daily"  { prefix = "daily/"   expiration { days = 30 } }
rule "monthly-cold"  { prefix = "monthly/"
  transition { days = 60  storage_class = "GLACIER_IR" }
  expiration { days = 365 } }

• प्रति-शाळा फाईल्स — शाळा #42 restore करताना इतर silos ना धक्काही लागत नाही (हाच पर्याय E चा मूळ हेतू).
• Backup monitoring: CronJob प्रत्येक शाळेसाठी success marker लिहितो; ताजा backup नसलेल्या शाळेवर रोजचा alert — गुपचूप fail होणारा backup हाच DR चा खरा शत्रू.
• Restore drills: दर महिन्याला एका random शाळेचा dump scratch instance मध्ये restore करून row-count तपासणी. कधीही restore न केलेला backup म्हणजे आशा — backup नव्हे.

school_features
  school_id      "sch_dps_pune"
  feature_key    "analytics" | "attendance"
                 | "fee_module" | "parent_portal"
  enabled        true
  source         "plan" | "school_admin" | "platform"
  updated_by / updated_at        # audited

• API: FeatureGuard (@Feature('fee_module')) बंद असताना 404 देतो — बंद feature "लपवलेले" नसते, ते अस्तित्वातच नसते.
• UI session मध्ये एकदा GET /me/features वाचते; server-side ६० सेकंद cache.
• Plan ही कमाल मर्यादा; school admins तिच्या आत मोकळेपणाने toggle करतात; platform panel मधून तुम्ही काहीही override करू शकता.

• सगळी infrastructure Terraform च्या मालकीची — VPC, EKS, RDS, S3 lifecycle, WAF, Route 53. State S3 मध्ये, DynamoDB locking सह; AWS console फक्त वाचण्यासाठी.
• Kubernetes manifests (Helm) त्याच repo मध्ये — इतर code प्रमाणेच review व version होतात.
• शाळेचे onboarding हा pipeline job, checklist नाही: DB + user + secret तयार, migrations, catalog मध्ये नोंद.
• production, sandbox व DR region साठी तेच modules — फक्त tfvars वेगळे. यामुळेच §8 चा runbook म्हणजे एक variable बदल — आठवणीतून पुनर्बांधणी नाही.

• फक्त दोनच cloud environments. Local dev म्हणजे laptop वरचे docker-compose — मोफत, deploy केलेले environment नव्हे.
• sandbox — production च्याच आकाराची पण छोटी प्रतिकृती: single-AZ RDS, spot nodes, दोन demo शाळा. प्रत्येक merge वर आपोआप deploy; restore drills व demos इथेच चालतात.
• production — सर्व काही multi-AZ; बदल फक्त pipeline च्या manual gate मधूनच येतात.
• DR — कायमस्वरूपी environment नाही: code (git) + replicate झालेल्या images (ECR) + बॅकअप (S3) हीच संपूर्ण system — त्यामुळे कायम खर्च जवळपास शून्य.

• Database-per-school ≠ instance-per-school — अनेक शाळांचे silo databases एकाच RDS instance वर राहतात, तरी पर्याय E चे isolation कायम (वेगळा DB + वेगळी credentials). मोठ्या शाळांना गरज पडेल तेव्हाच स्वतंत्र instance.
• Savings Plans / reserved instances — वापर स्थिर झाल्यावर EC2 + RDS वर ३०–४०% सूट.
• Graviton (t4g / m6g / r6g) — टेबलात आधीच गृहीत, x86 पेक्षा ~२०% स्वस्त.
• Spot nodes — sandbox व backup CronJobs साठी.
• S3 / ECR साठी VPC endpoints — NAT चा data-processing खर्च कमी होतो.
• §7 चे lifecycle नियम हेही खर्च-नियंत्रणच — तासागणिक १० दिवसांत जातात, ६० दिवसांनी Glacier.

• AWS Budgets — मासिक लक्ष्याच्या ८०% व १००% वर alerts; anomaly detection चालू.
• Cost-allocation tags सर्वत्र (env, जमेल तिथे school_id) — मग Cost Explorer प्रति शाळा खर्च दाखवतो.
• आठवड्याला खर्चाचा आढावा हा ops चाच भाग — uptime सारखा. लक्ष ठेवायचा आकडा म्हणजे प्रति-शाळा खर्च: शाळा वाढतील तसा तो घटत गेला पाहिजे.