tc-performance
.NET 8 API plus five TypeScript Lambdas giving Travel Counsellors a performance dashboard (commission, franchise, contacts, leaderboards, top customers) served from MongoDB read models refreshed from Snowflake.
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, typescript |
| Frameworks | ASP.NET Core 8, MediatR, AWS Lambda, Serilog |
| Runtimes | .NET 8, nodejs 20 |
| Tests / CI | some / CI in place |
| Last commit | 2026-04-02 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Data and insight (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | AWS Deployed to AWS
|
| Releases | 0 release pipeline(s): |
| Integration | rest, jwt |
| Source | Open in Azure DevOps |
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
Depends on / used by
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. Already deploys as a container to AWS, which releases without downtime today. Separating it from the three-week release is a process decision, not a technical one.
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Raise automated test coverage first: ZDD trades the end-of-sprint manual gate for continuous automated confidence, so the tests are the entry ticket.
- 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.
- Use ECS rolling deployments with health checks gating traffic, and take this service off the three-week release train.
- 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
Already containerisedIts pipelines already build containers and deploy to AWS. Nothing to do here.
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
tc-performance
Purpose
The "TC Performance" dashboard backend, letting agents evaluate their own performance. Five Node Lambdas (tc-perf-monthly-totals-commissionEarner, -contacts, tc-perf-my-franchise, tc-perf-top-customers, tc-perf-leaderboards) query the Snowflake data warehouse (key-pair auth, secrets from SSM) and write pre-computed collections (FranchiseBookings, CommissionEarnerMonthlyTotals, ContactMonthlyTotals, SalesPersonCompanyLeaderBoard, TopAccounts) into a TCPerformance MongoDB; the ASP.NET Core API then serves them through Accounts, CommissionEarner, Configuration, Franchise and Team controllers.
Tech stack
C# on .NET 8 (API, DataAccess, Common, Shared projects): MediatR, FluentValidation, Asp.Versioning, Serilog, Swashbuckle, PhenixAuth/Phenix.Auth.JWTBearer, TC.ConnectionBroker (Api/HttpClient/Mongo), TC.ScriptRunner.Mongo migrations. Lambdas are TypeScript/webpack with snowflake-sdk, the mongodb driver and @aws-sdk/client-ssm.
Deployment
No classic release pipelines (release_count 0). azure-pipelines.yml builds the API container via the shared InternalOSS/azure-pipelines-templates ci.yml (SDK 8.x, namespace phenix, ECS via aws-phenix-tc-apps tfvars, functional area phenix); build-node.yml ships the five Node 20 Lambdas to tc-phenix-function-artifacts. Build pipelines: tc-performance, tc-performance Node Lambdas. README carries build badges and links a SharePoint architecture diagram.
Dependencies
Internal packages: TC.ConnectionBroker.* (tc-connectionbroker), TC.Exceptions.WebApiClient.AspNetCore (tc-exceptions), TC.Diagnostics.HealthChecks (tc-diagnostics-portal), plus PhenixAuth for JWT validation. External: Snowflake warehouse (the sole data source for all performance figures), AWS SSM/Lambda/ECS.
Data stores
Owns the TCPerformance MongoDB database (written by the Lambdas, read by the API, Mongo script-runner migrations). Also reads the UserAccounts MongoDB database/UserAccount collection directly — a shared store owned by the user-account domain, coupling this API to its schema.
Integration points
Inbound REST (versioned, Swagger, PhenixAuth JWT). Outbound Snowflake SQL from the Lambdas and MongoDB writes; no message bus or WCF.
Code health
Reasonable: two NUnit/xUnit test projects for Common and Shared layers plus Jest specs for the Lambda shared services (~141 tests overall), but the API/DataAccess layers themselves have no dedicated test projects. Substantive README with architecture link, build badges and prerequisites. Last commit 2026-04-02.
Modernisation risks
Low. Modern .NET 8/Node 20 on ECS/Lambda with YAML CI. Residual concerns: direct reads of the shared UserAccounts Mongo database rather than going through the owning service's API; all dashboard accuracy depends on Snowflake query logic embedded in Lambda code (SnowflakeQueryBuilder), which only Jest unit tests cover; test coverage of the API layer is thin.