tc-redis-cache-event-socket-server
Tiny Node/TypeScript socket.io server that subscribes to TC.Cache Redis pub/sub events (CacheEntryCreated/CacheEntryRemoved) and rebroadcasts them to websocket clients for the cache event viewer.
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 | typescript |
| Frameworks | Express 4, socket.io 2 |
| Runtimes | Node 8.12 |
| Tests / CI | none / CI in place |
| Last commit | 2018-10-18 |
| 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 | 1 release pipeline(s): redis-cache-event-viewer |
| Integration | redis, websocket |
| Source | Open in Azure DevOps |
Risk flags
Each flag links to its glossary definition.
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
Ready with guardrailsClose: the deployment path exists, but specific checks are needed first, typically raising tests, auditing serialized data, or respecting a shared schema with expand and contract. Already deploys as a container to AWS, which releases without downtime today. No automated tests: at-will release without a safety net is bravado, not capability.
- 1 system(s) depend on this repo; during a rolling deploy they will talk to old and new versions at once, so responses must stay compatible
- 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.
- 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
Replatform tc-redis-cache-event-socket-server to modern .NET
Runs on Node 8.12, out of mainstream support. No pinning dependency blocks it; sequence by fan-in (providers before consumers).
Impact: Unblocks 1 dependent system(s)
proposedAssessment notes
tc-redis-cache-event-socket-server
Purpose
A ~35-line websocket bridge: it subscribes to the CacheEntryCreated and CacheEntryRemoved Redis pub/sub channels published by the TC.Cache layer and emits each message to all connected socket.io clients. Its only known consumer is tc-redis-cache-event-viewer, which renders the event stream.
Tech stack
TypeScript (single src/app.ts) compiled with tsc 3.1, running Express 4 + socket.io 2.1 + ioredis 4 on Node 8.12 (alpine Docker image). No framework beyond that.
Deployment
prod_application with 1 release via the shared redis-cache-event-viewer release pipeline, fed by classic build pipeline tc-redis-cache-event-socket-server master (no YAML in repo). Ships as a Docker image (tcdevelopment/tc-redis-cache-event-socket-server) via a two-stage Dockerfile; a generate-compose-file.sh script emits a docker-compose file pairing it with a Redis container. Listens on port 5000.
Dependencies
No internal estate packages. External npm: express, socket.io, ioredis (plus the meaningless http@0.0.0 package). No auth of any kind on the socket endpoint.
Data stores
Subscribes (read-only, pub/sub) to the TC.Cache Redis instance. The Redis host is hardcoded in source as dockerdev.travelcounsellors.com:6379 — a dev hostname with no environment-based configuration.
Integration points
Redis pub/sub inbound; socket.io websockets outbound to browser clients.
Code health
No tests (npm test is the default failing stub), boilerplate Azure DevOps README, no linting, single source file. Dormant since 2018-10-18 — untouched for nearly eight years while still release-linked.
Modernisation risks
Node 8 has been end-of-life since 2019, and socket.io 2/ioredis 4 are similarly outdated. The hardcoded dev Redis hostname suggests the production deployment either patches the source or points at a stale target — worth verifying it still serves any purpose. Given its size, the realistic options are retiring it together with the viewer or rewriting the bridge in an afternoon on a supported runtime.