tc-match
Single .NET 8 Lambda-hosted HTTP API that matches a prospective customer to the best-fit Travel Counsellors by querying a Snowflake ML model, returning agents ranked by probability score.
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 | AWS Lambda (Amazon.Lambda.APIGatewayEvents), FluentValidation, Mapster |
| Runtimes | .NET 8 |
| Tests / CI | some / CI in place |
| Last commit | 2026-06-22 |
| 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.
- 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-match
Purpose
"TC Match" for the public website: one Lambda function (TC.Match.Functions.CustomerTcMatch, GetCustomerTcMatchFunction) behind an API Gateway HTTP API takes a country code and free-text customer content, calls a Snowflake-hosted matching model, and returns Travel Counsellors ordered by probability score with a query ID. Effectively an ML-inference facade — the matching intelligence lives in Snowflake, not in this repo.
Tech stack
Tiny, modern C# on .NET 8: Amazon.Lambda.Core/APIGatewayEvents with System.Text.Json serialization, FluentValidation, Mapster, Microsoft.Extensions.Caching.Hybrid (caching Snowflake credentials), System.IdentityModel.Tokens.Jwt for building the JWT used to authenticate to Snowflake, AWSSDK SimpleSystemsManagement for SSM Parameter Store secrets. One solution, one function project, one test project.
Deployment
No release pipelines (release_count 0); single build pipeline tc-match-lambdas from azure-pipeline-lambdas.yml using the shared InternalOSS/azure-pipelines-templates ci.yml with the lambda_http_apis parameter set: artifacts to the tc-public-function-artifacts bucket, deployment group tc-match-lambdas, Terraform tfvars deployment via aws-public-tc-apps, functional area public.
Dependencies
No internal TC packages at all — it references only AWS SDK and mainstream OSS libraries. External: the Snowflake REST endpoint (base URL from SNOWFLAKE_BASE_URL env var; account/key secrets fetched from SSM Parameter Store and cached).
Data stores
None owned. Snowflake is queried as an external ML/analytics service, not managed by this repo.
Integration points
Inbound REST via API Gateway; outbound HTTPS to Snowflake authenticated with a self-generated JWT. No message bus, no MongoDB/SQL.
Code health
Reasonable for its size: one xUnit test project with 16 tests (manager/validator/client coverage), the shared CI template runs tests, global.json pins the SDK. README is untouched boilerplate. Last commit 2026-06-22.
Modernisation risks
Low. Modern .NET 8 serverless code with secrets correctly held in SSM rather than source. Main risks are external: coupling to the Snowflake model contract and account (any model or auth change breaks matching), and the boilerplate README leaves the Snowflake query contract undocumented.
Data store follow-up (2026-07-28)
Follow-up scan of project files, configuration and the central Terraform repos confirmed the empty data_stores list is correct. Lambdas using only the AWS SSM SDK; no data store packages or configuration found.