tc-public-reviews-api
.NET 8 API for customer reviews on the public website — consuming review events from SQS into a PublicReviews MongoDB read store, serving review shells and destination reviews over REST, and re-publishing events to AWS EventBridge.
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 12, FluentValidation 11, Mapster |
| Runtimes | .NET 8 |
| Tests / CI | good / CI in place |
| Last commit | 2026-01-05 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Content and destinations (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, sqs, eventbridge |
| Source | Open in Azure DevOps |
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. 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.
- 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.
- 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-public-reviews-api
Purpose
The public-website end of the reviews platform. A MessageQueueHostedService polls an SQS queue for the ReviewShellCreated/Updated and LocationReviewUpdated events that tc-reviews-sync-service emits from the on-prem Reviews database, dispatches them through MediatR handlers into a PublicReviews MongoDB store, and deletes each message only after successful processing. ReviewsController and DestinationsController then serve review shells and per-destination reviews to the website; command endpoints (create/update review shell, update state, update destination review) also publish events onward to an AWS EventBridge bus.
Tech stack
C# on .NET 8 across five projects (Abstractions, Api, Application, Messaging, Persistence). MediatR 12 with a hand-rolled command/query/event handler abstraction and Scrutor scanning, FluentValidation 11 with a model-validation action filter, Mapster, MongoDB.Driver 3.5, correlation and logging middlewares with a Swagger correlation-header filter, TC.ScriptRunner.Mongo migrations, TC.Diagnostics health checks, a Reviews.rest HTTP scratch file for manual testing.
Deployment
Included as prod_application with 0 releases — YAML/AWS only. Build pipeline tc-public-reviews-api from azure-pipeline.yaml on the shared InternalOSS/azure-pipelines-templates jobs/ci.yml (SDK 8.x): container into cx-public, ECS via the aws-public-tc-apps Terraform repo with tfvars, eu-west-1, functional area public. Per-environment appsettings (development, qa, preproduction, production).
Dependencies
Internal: TC.ConnectionBroker.* including the AWS broker (tc-connectionbroker), TC.Exceptions.WebApiClient.AspNetCore (tc-exceptions), TC.Diagnostics.HealthChecks (tc-diagnostics-portal); runtime coupling to tc-reviews-sync-service through the shared review event contracts on SQS. External: AWS SQS (broker target ReviewsMessagingSqs) and EventBridge (broker target PublicOnPremEventTestProducer — a name that still says "test" in production code).
Data stores
Owns the PublicReviews MongoDB database (reviews, destinations) via the Mongo connection broker, with script-runner migrations at startup.
Integration points
Inbound REST (no authentication package is wired in — endpoints appear anonymous, appropriate for public review content but worth confirming for the write endpoints); inbound SQS event consumption; outbound EventBridge publication.
Code health
Good: four unit-test projects plus a shared test library, ~144 facts/theories covering API, Application, Messaging and Persistence. README is untouched Azure DevOps boilerplate. Last commit 2026-01-05 — recently maintained.
Modernisation risks
Low. Modern .NET 8, containerised, well tested. Watch items: write endpoints without visible authentication, the "PublicOnPremEventTestProducer" EventBridge target name suggesting temporary plumbing that stuck, and the SQS event contract shared informally (copied classes rather than a versioned package) with tc-reviews-sync-service.