title: stgapi (staging): phase 1 design (Oct–Dec 2026)
component: stgapi
level: phase
period: sprints S2–S5 (1 Nov – 26 Dec 2026)
status: draft 1 (25 Oct)
owner: MMDEP Design (Claude)
decisions: TD-051, TD-052, TD-055
overall: stgapi/overall.md
queues: docs/prompts/api-lane-s/S2/QUEUE.md (S1–S6)
stgapi (staging): phase 1
1. Goal
By the end of phase 1 stgapi is provably isolated, runs the next release with real-enough data, and is where every API and MM-Cron change, and every consumer's acceptance, happens first.
2. Baseline (collector, 25 Oct)
| Check |
Value |
/api/health |
200 (Release-C 825127e0) |
/api/schemes |
200, 1 scheme (production: 10,008) |
/api/scheme/nav?scheme_code=120245 |
200, 3,333 rows, latest 19 Aug (production 23 Oct), 1 duplicate date |
/api/index/nav?symbol=NIFTY 50 |
404 (only NIFTYM150MOMNTM50 is seeded) |
/api/nfos/active |
500 |
/category |
200, 1 category (production: 180) |
| Isolation |
Unproven (X1, three accounts) |
3. Staging data scope (TD-055)
Copying all NAV history (~37M rows) through public routes would load production for days and gain little. Phase 1 staging data is:
| Data |
Scope |
How |
| Catalogue |
All products, owners, categories, fund details |
Loader from production GET routes, weekly |
| Scheme master |
All schemes (10k) |
Loader once; then MM-Cron staging runs (S5 job) |
| NAV history |
The staging set: PE's 25-fund universe, the 10-scheme parity sample, MWMC's fund-page pilot schemes, and one scheme per category (about 200 schemes in all), full history |
Loader through stgapi /save-nav, de-duplicated, gaps flagged |
| NAV daily |
All schemes from the start date of MM-Cron staging runs |
MM-Cron AMFI daily job (one file covers all schemes) |
| Index values |
NIFTY 50, NIFTYM150MOMNTM50 and the benchmarks of the staging set, full history |
Loader, then MM-Cron |
| Holdings, fund details (new) |
Whatever the AMC adapters produce |
MM-Cron staging runs |
The staging set is a file in the api repo (docs/staging-set.yaml) that PE, MWMC and the parity check share. A consumer that needs another scheme adds it there.
4. Milestones
| # |
By |
Milestone |
Measured by |
| SG-1 |
4 Nov |
Isolation proven (read-only check of effective DB targets and grants), recorded in runs/S2.md; resource caps on mm-stgapi.service; deploy-staging restarts through systemd |
Run file; systemctl show values; a CI deploy that leaves PID management to systemd |
| SG-2 |
14 Nov (S2 end) |
Promotion and first data: api-phase1-development promoted to api-phase1-staging-release (brings !147, !132, !162); catalogue and scheme master loaded; staging-set NAV and indices loaded; /api/index/nav and /api/nfos/active fixed (S3) |
Collector: schemes ≈ production; categories = 180; index and NFO routes 200 |
| SG-3 |
28 Nov (S3 end) |
Living staging: MM-Cron staging runs daily (NAV, TER, adapters); write keys enforced; contract tests and daily parity in CI; release 3 RC accepted here by MWMC and MCRM |
NAV ≤ 1 business day behind production; parity report with every difference classified |
| SG-4 |
12 Dec (S4 end) |
Rehearsal ground: NAV de-dup rehearsed (P2); ingest routes exercised by all adapters; restore drill on staging from production backups (roadmap §3) |
Rehearsal evidence in the P2 RC; restore drill log |
| SG-5 |
26 Dec (S5 end) |
Clean: legacy staging schemas retired (G4), staging DB users rotated, runbook current |
Schema list; rotation record |
5. Interfaces that change
| Interface |
Change |
deploy-staging (api .gitlab-ci.yml) |
Automatic on merge to api-phase1-staging-release; restart via sudo systemctl restart mm-stgapi |
mm-stgapi.service |
MemoryMax, CPUQuota, TasksMax added (values from the host size, set in SG-1) |
docs/staging-set.yaml (api repo) |
New, shared by loader, parity check, PE and MWMC |
| Parity report |
New daily output in the collector |
| Write routes on stgapi |
Staging keys; production keys rejected |
6. Risks
| Risk |
Mitigation |
| The isolation check shows stgapi reading production databases (account c) |
Stop all staging writes; fix the configuration to staging DBs first (high risk, Lane P plus Atul); data load waits |
| Loader puts load on production |
One request at a time with a delay, off-hours, staging set only (TD-055) |
| Staging differs from production after de-dup |
Parity classifies differences instead of failing; differences listed in the RC |
| Lane S agent (API-2) not revived yet |
Current agent takes S1–S3 lightly; harness takes the cx 1–2 items |
| Host memory too small for caps plus production |
Measure first (SG-1); if too tight, move stgapi to the new server (SRV-1) |
7. What "done" means for phase 1
- [ ] A recorded read-only proof that stgapi reads and writes only
mm_api_staging and mm_nav_staging.
- [ ] stgapi serves the full catalogue and scheme master, the staging set's full NAV and index history, and daily NAV for all schemes, at most one business day behind production.
- [ ] Every smoke, contract and parity check runs in CI on each deploy; every parity difference is classified.
- [ ] Every production release in phase 1 was deployed, tested and accepted (MWMC, MCRM) on stgapi first.
- [ ] Caps in place; no production slowdown traced to stgapi.