• http://localhost:4022

Isolated rehearsal gateway:

• http://localhost:4002

This used an isolated API instance so the existing 4001 stack did not need to be interrupted.

Env settings used

Fallback mode:

• PORT=4002
• no ACCOMMODATIONS_SERVICE_URL override
• services/api/.env continued to point accommodation traffic at http://localhost:4020

Cutover mode:

• PORT=4002
• ACCOMMODATIONS_SERVICE_URL=http://localhost:4022

Rollback mode:

• PORT=4002
• removed the ACCOMMODATIONS_SERVICE_URL override again

Cutover steps

1. start old svc-tenders accommodation host on 4020 if not already running
2. start new svc-accommodations host on 4022
3. start isolated API on 4002 in fallback mode
4. verify fallback gateway responses against old host
5. restart isolated API on 4002 with ACCOMMODATIONS_SERVICE_URL=http://localhost:4022
6. verify cutover gateway responses against new host

Rollback steps

1. stop the cutover-mode API process on 4002
2. restart API on 4002 without the ACCOMMODATIONS_SERVICE_URL override
3. verify gateway responses match old svc-tenders accommodation host again

Observations

Fallback rehearsal:

• gateway matched old host for checked public, authenticated, and denial-path routes

Cutover rehearsal:

• gateway matched new svc-accommodations host for the same checked route set

Rollback rehearsal:

• after removing the override, gateway matched old host again

Auth observations:

• auth-protected owner and booking-read routes behaved the same through fallback and cutover
• missing-token mutation denial stayed unchanged

Quote observation:

• quote payloads matched except for request-time computedAt timestamp differences

Remaining risks

• compatibility residue still exists in old-host-only accommodation compatibility reads, even though it did not surface in the checked route set
• no authenticated happy-path write mutation was exercised through the gateway in this sprint
• live cutover should still treat migration ownership and compatibility residue as open truths, not solved problems