kafka-consumer
.NET 8 containerised console service that consumes third-party Kafka topics (currently Travelport hospitality streaming trip alerts) and forwards each message to AWS EventBridge buses for downstream estate consumers.
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 | Confluent.Kafka 2, OpenTelemetry, Generic Host |
| Runtimes | .NET 8 |
| Tests / CI | good / CI in place |
| Last commit | 2025-10-16 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Platform services (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | AWS Deployed to AWS
|
| Releases | 0 release pipeline(s): |
| Integration | kafka, eventbridge |
| 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.
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.
- 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
kafka-consumer
Purpose
A generic inbound bridge for third-party Kafka feeds: a KafkaListenerService subscribes to configured topics and fans each message out through pluggable forwarders (currently eventbridge and log). One ECS instance is deployed per external Kafka cluster/environment; today that means Travelport's hospitality-streaming cluster, forwarding tc-event-listeners-tcounsellors-{qa,prod} topics as TripActivityAlert events onto the {qa,prod}-notifications EventBridge buses, from where EventBridge rules route into the phenix/public/cx/payments accounts.
Tech stack
Single modern C#/.NET 8 console project, deliberately lean: Confluent.Kafka 2.10 over SSL, AWSSDK EventBridge and SimpleSystemsManagement, OpenTelemetry (console + OTLP exporters, runtime instrumentation), source-generated JSON and configuration binding, IsAotCompatible and invariant globalisation enabled. No internal TC NuGet packages at all.
Deployment
No classic release pipelines (release_count 0); traced via build->yaml-deploy, build pipeline kafka-consumer. build.yml uses the shared InternalOSS/azure-pipelines-templates ci.yml on LinuxAgents with containerAfterBuild: true, container namespace devops, eu-west-1 and useTFVarsDeployment: false — a Docker image run on ECS, one container per Kafka connection selected by appsettings.{provider}_{env}.json (travelport_qa, travelport_prod checked in).
Dependencies
No internal estate repos. External: the Travelport hospitality-streaming Kafka cluster (13 brokers on hospitality-streaming.travelport.com) and AWS (EventBridge event buses, SSM Parameter Store for the Kafka CA certificate, referenced by ARN — no secrets in source).
Data stores
None. State is limited to an in-memory SSM parameter cache and Kafka consumer-group offsets held broker-side.
Integration points
Inbound: SSL Kafka consumption from external vendors. Outbound: AWS EventBridge PutEvents per configured forwarder. The forwarder abstraction anticipates future targets (own Kafka, MassTransit, Redis) but only EventBridge and console logging exist.
Code health
Good: one xUnit test project with ~85 tests including config validation, forwarders, listener lifecycle and end-to-end tests (with a LibrdKafkaLimitationsFact attribute for environment-dependent cases). Substantive README with an infrastructure diagram and per-forwarder configuration docs. Last commit 2025-10-16.
Modernisation risks
Low — a small, modern, well-tested single-purpose service. Watchpoints: it is a single point of ingress for vendor notifications (an outage queues messages broker-side, relying on Travelport retention), useTFVarsDeployment is false so its ECS/Terraform definition lives elsewhere and must be kept aligned, and adding new providers means multiplying per-provider config files and containers.
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. Consumes the Travelport Kafka feed and forwards events to Amazon EventBridge (Terraform: aws-notifications-tc-apps ecs_task/travelport-kafka-consumer.tf); stateless bridge, no data store.