Platform Evolution
Assessment run-2026-07-27-1 · 213 of 213 repos assessed
Repos / tc-referrals

tc-referrals

.NET 10 API plus an AWS Lambda webhook receiver integrating the Mention Me referral-marketing platform — ingesting referral/NPS webhooks, recording bookings as Mention Me orders, and tracking referrers and referees in a Referrals MongoDB store.

96 · greenlowloosely attachedAWSZDD: no excuseapi

Health score

96

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.


Runtime currency / 25
25
Runs on supported modern .NET
Legacy transport / 15
15
No legacy WCF or SOAP surface
Test posture / 15
15
Good test coverage
Security hygiene / 15
15
No credentials found in source
Dangerous coupling / 15
11
depends on pinning component(s): phenix-feature-service
Activity / 10
10
Actively maintained
Deployment hygiene / 5
5
CI in place
Health over time
2026-07-27 (run-2026-07-27-1): 96
Baseline 96 recorded 2026-07-27. The trend fills in with each monthly assessment run.

Facts

Languagescsharp
FrameworksASP.NET Core 10, MassTransit 8, FluentValidation 12, Mapster, AWS Lambda
Runtimes.NET 10
Tests / CIgood / CI in place
Last commit2026-07-03
OwnerOwner unknown (mapping to be curated)
DomainPublic web (system generated; curate in repo-owners.json to override)
Product areaShared platform
HostedAWS Deployed to AWS
  • build "tc-referrals" (azure-pipeline.yaml): AWS signal "ecsTerraformRepo"
  • build "tc-referrals-lambdas" (azure-pipeline-lambdas.yml): AWS signal "ecsTerraformRepo"
Releases0 release pipeline(s):
Integrationrest, masstransit, sqs
SourceOpen in Azure DevOps

Risk flags

Each flag links to its glossary definition.

Dependencies in context

Laying out the graph…
greenamberreddata store (square, dashed link)Node size follows fan-in. Click any node to open it.

Entanglement

loosely attached Bound into the core by 1 mechanism(s).

Detaches when its pinning dependencies are cut or multi-targeted (phenix-feature-service).

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 excuse

Nothing 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.

Dependencies and gotchas
  • Serialized state or messages in flight (Redis or queues): new code must deserialize objects written by the previous version
  • Feature flags come from phenix-feature-service (WCF-only): flag reads themselves are a legacy dependency to watch
Steps
  1. Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
  2. 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.
  3. Audit serialized data: anything in Redis, queues or shared caches must deserialize cleanly across adjacent versions.
  4. Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
  5. Use ECS rolling deployments with health checks gating traffic, and take this service off the three-week release train.
  6. 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 applicable

No SQL Server dependency is recorded for this repo. Nothing to migrate.

Containerisation

Already containerised

Its 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-referrals

Purpose

Integration with the external Mention Me referral platform. The TC.Referrals.MentionMe.Webhooks Lambda sits behind API Gateway, HMAC-verifies incoming Mention Me webhooks using secrets from SSM Parameter Store, and dispatches thirteen typed events (referrer/referee registered and fulfilled, NPS score/feedback, marketing consent, propensity segments, metrics) onto MassTransit/SQS. The API consumes those events into MongoDB, consumes estate BookingChangedEvents to record orders back to the Mention Me API (gated by company-info and feature-flag checks), and exposes an EnrolReferrer endpoint; a published TC.Referrals.Api.Client lets other services call it.

Tech stack

C# on .NET 10 — the most modern stack seen in the estate. ASP.NET Core minimal-endpoint style with OpenAPI/Scalar, MassTransit 8.5 over Amazon SQS with TC.MassTransit.AmazonSQS conventions, FluentValidation 12, Mapster, FluentResults, Polly, MongoDB.Driver 3.9 with TC.ScriptRunner.Mongo migrations, TC.Cognito.Auth.Client for outbound auth to the public travel counsellors API, hybrid caching in the Lambda.

Deployment

Included as prod_application with 0 releases; two build pipelines, tc-referrals and tc-referrals-lambdas, both on the shared InternalOSS/azure-pipelines-templates jobs/ci.yml (SDK 10.x). The API is containerised (containerNamespace: cx) to ECS via the aws-cx-tc-apps Terraform repo with tfvars (functional area cx); the path-filtered lambdas pipeline publishes the webhook function to the tc-cx-function-artifacts S3 bucket as a lambda_http_apis deployment group tc-referrals-lambdas. Contracts and Api.Client NuGet packages are packed by the main pipeline.

Dependencies

Internal: TC.ConnectionBroker.* including AWS broker (tc-connectionbroker), TC.Diagnostics.HealthChecks (tc-diagnostics-portal), TC.Phenix.CompanyInfo (company-info-api), TC.Phenix.Feature (phenix-feature-service), TC.StreamsMassTransitAdapter.Events booking-changed contracts (tc-streams-masstransit-adapter), and a REST client plus contracts for tc-public-travelcounsellors (currently borrowing the MailScheduler connection-broker tag, per a code TODO). External: the Mention Me partner API (order recording, segments) and Amazon SQS/SSM.

Data stores

Owns the Referrals MongoDB database (Referrers, Referees, MentionMeEvents collections) via connection-broker target Referrals, with script-runner index migrations.

Integration points

Inbound REST (API) and API-Gateway-fronted Lambda webhook with HMAC signature verification; MassTransit over SQS both inbound (Mention Me events, booking-changed events) and within the estate; outbound REST to Mention Me and the public travel counsellors API with Cognito-authenticated calls.

Code health

Good: ~85 facts/theories across API and MentionMe-service unit-test projects plus a client test console; secrets kept in SSM rather than source. README is untouched boilerplate — notable for a repo with this many moving parts. Actively developed (last commit 2026-07-03).

Modernisation risks

Low — this is the estate's leading edge (.NET 10, containers, Lambda, MassTransit). Residual points: hard dependency on the external Mention Me contract across thirteen webhook payload types, the borrowed MailScheduler broker tag for the travel-counsellors client, and no documentation of the webhook-to-consumer event flow.