phenix-retail-api
.NET 8 API extracting Phenix Retail functionality (per-company retail configuration flags and the Mongo/Atlas-backed surname quick search) out of the legacy MVC app and SQL Server.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | csharp |
| Frameworks | ASP.NET Core 8, MediatR, FluentValidation |
| Runtimes | .NET 8 |
| Tests / CI | good / CI in place |
| Last commit | 2026-01-06 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Selling and quoting (system generated; curate in repo-owners.json to override) |
| Product area | Phenix |
| Hosted | On-prem Deployed to our own machines
|
| Releases | 1 release pipeline(s): \finance\phenix-retail-api |
| Integration | rest, redis, redis-streams |
| Source | Open in Azure DevOps |
Risk flags
No risk flags recorded.
Each flag links to its glossary definition.
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
No excuseNothing technical is holding this repo on the three-week release. It either already deploys without downtime (AWS) or is a modern, well-tested service the automated stealth path can carry today. Modern runtime, good tests, no hosted legacy transport: the automated stealth path can carry it today.
- 1 system(s) depend on this repo; during a rolling deploy they will talk to old and new versions at once, so responses must stay compatible
- Serialized state or messages in flight (Redis or queues): new code must deserialize objects written by the previous version
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Make every change dual-version safe: backwards-compatible APIs (new major version for breaking wire changes), expand and contract for any schema change, and consumers tolerant of unknown fields.
- Audit serialized data: anything in Redis, queues or shared caches must deserialize cleanly across adjacent versions.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Route deployments through the Workflow Engine's automated drain, deploy, health-check, return cycle (the path proven by the first automated production run in mid-2026).
- Verify with area-scoped regression rather than the whole-platform cycle, and watch error rates after rollout with automated rollback on alert.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Ready to containeriseModern runtime, no hosted legacy transport: this service can follow the estate's proven container path (Dockerfile, shared pipeline template, ECS via Terraform).
- Add a Dockerfile and make the app read all configuration from environment variables and the secrets manager, never from machine-local files.
- Log to stdout and expose a health check endpoint so ECS can supervise it.
- Adopt the shared ci.yml pipeline template with the container parameters (awsRegion, containerAfterBuild, ecsTerraformRepo), which is exactly how the estate's existing AWS services deploy.
- Define the service in the Terraform repo, deploy to a non-production environment, then shift traffic and disarm the deployment-group release pipeline.
Recommended actions
No specific actions for this repo. It either needs only normal maintenance, or its work is covered by an estate-level action. See the full programme.
Assessment notes
phenix-retail-api
Purpose
"An API to replace functionality in the Phenix Retail application, putting it into an API that can be called from an angular site." Two capabilities so far: retail company configuration (per-company feature flags stored as a flagged enum, migrated here from the retail configuration WCF service) and quick search (surname search for the Phenix top menu bar, moved out of SQL Server into MongoDB with Atlas search). Booking/customer/passenger change events raised in BackOffice are stored in Mongo, queued by booking id on a Redis queue, and a background service periodically rebuilds SurnameSearchModel documents.
Tech stack
C# on .NET 8: MediatR, FluentValidation, Asp.Versioning, Swashbuckle plus NSwag client generation baked into the build (the TC.Phenix.Retail.Api.Client package is regenerated from swagger). MongoDB.Driver 3.5 with TC.ConnectionBroker.Mongo, TC.ScriptRunner.Mongo change scripts, TC.Streams over Redis for event integration, Correlate correlation IDs, PhenixAuth authentication, TC health checks. One-off migration console tools live under tools/.
Deployment
Included as prod_application with 1 release (\finance\phenix-retail-api from build phenix-retail-api). YAML build.yml using the shared templates builds the API and publishes the Models/Client packages; a separate deploy-mongodb.yml handles Mongo change-script deployment.
Dependencies
Internal: TC.ConnectionBroker suite (tc-connectionbroker), TC.Exceptions.WebApiClient (tc-exceptions), and TC.Phenix.Accounts.Events — the event contracts raised by BackOffice (backoffice), which is the upstream producer for quick search. Its own client package is consumed by phenix-retail. External: MongoDB Atlas (Atlas search is load-bearing for quick search).
Data stores
MongoDB database PhenixRetail (raw event collections, surname search models, retail company configuration) and a Redis-backed queue/stream for pending search-model updates.
Integration points
REST (versioned controllers, generated client); Redis streams/queue for event-driven search-model rebuilds.
Code health
Good: single xUnit test project with ~197 tests, YAML CI, an unusually good README with architecture diagrams (LucidChart) explaining the quick-search event flow, and Mongo change scripts under source control. Last commit 2026-01-06.
Modernisation risks
Low — modern .NET 8, tested, documented. It is the strangler-pattern target for phenix-retail, so risk is mostly organisational: the extraction has covered only configuration and quick search so far, and the retail configuration WCF service it supersedes (phenix-retail-configuration-service) still exists in production, so there is duplicated capability until consumers are migrated.