growqr-app/matchmaking-v2
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
matchmaking-v2/research/docs/DECOMMISSION_PLAN.md
raulgupta 89ca9ad647 Initial commit: matchmaking-v2 on-demand multi-board job-search agent 
On-demand Scout service (replaces the nightly aggregator):
- FastAPI agent-mesh service; card name "matchmaking-service" (HTTP /a2a/tasks
  + Redis-stream worker matching the sibling-service pattern)
- run_search: parallel multi-board sweep (Naukri/blackfalcondata + Foundit +
  LinkedIn), city-filtered at the board, cheapest-per-result first
- per-board adapters + normalizers -> ScoutJob with rich read-only details and
  offsite apply links; recall mode + MVQ guard
- result cache for dev replay ($0); per-board cost knobs; retry-on-5xx
- research/: engine design, board cost economics, India-actor shortlist, POC
2026-06-18 19:22:03 +05:30

2.7 KiB
Raw Permalink Blame History

Old Matchmaking — Decommission & Slot-In Plan

How matchmaking-v2 (Scout) replaces the dead matchmaking service. Companion to ENGINE_DESIGN.md. Status (2026-06-16): planned, local teardown not yet executed.

Current state (verified live 2026-06-16)

The old matchmaking runs identically in both local (growqr-demo) and prod (EC2):

Component Local Prod (EC2 3.109.159.139)
matchmaking-api :8006 → 8000, up :8006 → 8000, up 4d
matchmaking-worker up up 4d
matchmaking-ingestion-worker up up 4d
matchmaking-postgres (own DB, NOT RDS) :5439, vol matchmaking-pgdata :5439, vol matchmaking-pgdata

Containers are running but the service is functionally dead (ingestion chain broke 2026-05-27; 986,770 stale score rows for 21 users). :8011 is free in both. AWS reachable: CLI as iam::189924572890:user/rahul; SSH ec2-user@3.109.159.139 (key ~/.ssh/growqr-key.pem).

Locked decisions

  1. Reuse port :8006 (the old matchmaking's slot) — NOT a new :8011. This overrides ENGINE_DESIGN.md §1's "12th agent on :8011". Rationale: in-place swap — v2 inherits the existing api.growqr.ai/matchmaking/* nginx route + the frontend's existing matchmaking wiring, so the Scout UI works with minimal rewiring.
  2. Drop the old corpus DB. v2 is on-demand, no corpus (ENGINE_DESIGN.md §1) — so matchmaking-postgres + its matchmaking-pgdata volume are discarded. The data is stale/worthless (design doc verdict). Irreversible — confirm before deleting the volume.
  3. WS-agent via orchestrator. v2 reuses :8006, registers in orchestrator AGENT_URLS, and the frontend reaches it through useAgentSession (WS) — matching the mesh pattern (like course-service :8010). The old /matchmaking/* nginx HTTP route stays vestigial or is removed later.

Sequence

A. Local — immediate (on go-ahead):

  • docker compose stop + rm the 4 matchmaking containers (api, worker, ingestion-worker, postgres).
  • Drop the matchmaking-pgdata volume (decision #2). Frees :8006 + :5439 for v2 dev.
  • Comment/remove the matchmaking services from the local compose; v2 takes :8006.

B. Prod — later (after v2 validated):

  • Stop the 4 prod matchmaking containers; remove from docker-compose.prod.yml.
  • Deploy v2 on :8006; add to orchestrator AGENT_URLS; keep/retire the nginx /matchmaking/* route.
  • Periodic docker builder/image prune (per aws-deployment.md) after the swap.

Rollback

Local teardown is reversible except the dropped volume. Keep the old matchmaking repo + compose definition until v2 is validated in prod, so prod can be restored by re-adding the service block.