0003 — Keep the fantasy modules and MongoDB

Status: superseded by 0010 (2026-08-10) — originally accepted 2026-07-23

Context

The restored backend is roughly half fantasy-sports machinery: Entity Sport sync, contests, teams, scoring, pick-one-player, predictions — with series/ match/team/prediction documents in MongoDB while commerce data lives in Postgres. The immediate product focus is the e-commerce store, which raised the question of stripping the fantasy modules (and with them the Mongo dependency) to simplify the stack.

Decision

Keep the fantasy modules and MongoDB. The owner confirmed that other clients may still depend on the fantasy endpoints, so removing them risks breaking consumers we don't control. Cutting Mongo would also mean porting the document-shaped sport data (nested squads, ball-by-ball scoring inputs, question books) into relational form — real work with real regression risk, for a dependency that runs happily as one more compose service.

Consequences

• The production stack carries three data stores (Postgres, MongoDB, Redis); aim_mongo gets the same backup treatment as Postgres (mongodump on every backend deploy).
• ENTITY_ACCESS_TOKEN remains a hard boot requirement of the backend — even a store-only deployment must supply it.
• The fantasy surface stays documented and tested rather than rotting in a branch; if it is ever formally retired, that gets its own ADR.