Integrating VIA Rail and JonView into a tour operator's booking system

Context

Fresh Tracks Canada sells Canadian rail vacations from Vancouver. Its booking management system is about 20 repositories: Django and FastAPI services, a Next.js front end, PostgreSQL, Elasticsearch, Redis, on AWS, with a two-way Salesforce sync. I have been its systems architect on contract since May 2023, working Pacific-time overlap from Mumbai and aligning technology work with the Director.

Constraint: the itinerary system stayed live throughout; every supplier had its own timeouts, outages and product quirks, and none of that could reach the sales team's screen.

Problem

Sales staff needed to search and book supplier products from inside the itinerary system; booking a single product by hand took about 10 minutes, and quotes went cold while they waited.

What I built

I integrated the JonView supplier API into the itinerary management system so staff search and book products in place, with supplier timeouts, downtime and itinerary-to-supplier state sync handled explicitly. Later I added dynamic hotel availability, product linking, synced cancellations and value-adds, and a rule that skips products with malformed supplier responses.

I then built the VIA Rail integration end to end and a Rocky Mountaineer scraper, and fixed the Redis cache timeouts and batch-job database connections that surfaced as the supplier module grew. I am the dominant author of the supplier module (124 of 330 commits).

Architecture

Django and DRF service (bms-service-supplier-connect) with a per-supplier client, a circuit breaker for JonView (jonview/circuit_breaker.py), a websocket router and consumers for live updates, Redis caching, batch jobs for availability, PostgreSQL, and GitHub Actions per-environment deploys.

1. Sales staff in the itinerary system (Next.js)
2. Supplier-connect service (Django, DRF)
3. Per-supplier client with circuit breaker and timeouts
4. JonView, VIA Rail, Rocky Mountaineer APIs
5. State sync back to the itinerary and websocket updates to the screen

Rails to Django migration, the groundwork

Before the supplier work I led the migration of a Ruby on Rails application to Django and React. I redesigned the process logic with the Product Owner first, then migrated the app. API response times got 80 to 95% faster by minimizing SQL calls and caching static data in a NoSQL store (client report; self-reported percentage).

Stack Python, Django, Django REST Framework, PostgreSQL, Redis, WebSockets, AWS ECS, GitHub Actions, Salesforce, SonarQube

Results

Per-product booking time went from about 10 minutes to about 30 seconds, and quote conversion improved (the client’s figure; I do not publish a percentage I cannot source). Three supplier integrations are live.

Alongside this I designed, built and documented alone a PostgreSQL fleet monitor (11 metrics, alert thresholds, add a server by editing one secret, no deploy) whose spec was approved before a line of code, on 23 July 2026; it has its own case study. I also designed and prototyped CrewAI agents for the 20 to 50 daily supplier emails the operations team handles, with human approval through Teams Adaptive Cards; whether that prototype went live is not something I will claim here.

What I'd do differently

On VIA Rail, graceful failure handling was the last step in the sequence. Next time I would pull the failure-mode list (timeouts, supplier downtime, malformed product responses, state drift between our system and theirs) to the front and build the circuit-breaker path in the first week, because those four classes are what every supplier integration on this project eventually needed.