Project Name
Ksolves Merges Four Travel Inventory Sources Into One Live Panel With Zero Hot-Path Calls
Every sales call for a multi-day rail-and-hotel package meant an agent juggling four separate inventory systems just to answer one question: can I sell this date? Internal stock, a hotel reseller network, two rail carriers, each checked separately, mid-call. Skip a check, or catch it too late, and agents were left guessing on the phone or cleaning up a broken booking afterward. Ksolves built a single live panel that answers that question instantly, without the agent knowing or caring which of the four sources the answer actually came from. The console now makes zero live external calls on the sales hot path, and the whole system runs for about $90 a month.
- No unified view of availability across four systems: Agents checked internal inventory, the hotel reseller network, and two rail carriers separately, mid-call, before confirming any date.
- One rail carrier had no trade relationship or booking API: This carrier's availability lived only on its public consumer website. No booking API, no trade relationship, no sanctioned way to query it.
- Hotel availability didn't map cleanly to what was actually sold: The room class actually booked for a night often wasn't the class the trip was sold at, so a simple room count would have misled agents more often than it helped them.
- Any live external dependency risked stalling the sales call: If the panel had to wait on a live fetch from a partner site or API, a slowdown on their end would stall the call the agent was on.
- No fallback existed when an automated feed failed: A broken sync had exactly one recovery path, an engineer, in production, by hand.
- Operators couldn't tell "feed is down" from "feed is quietly wrong": A scraper that had crashed and one that ran fine but returned suspiciously thin data needed completely different responses. Nothing told them apart.
The core decision Ksolves made was simple to state and hard to build: the read path is agent-facing, never fetch-facing. Every external source is pulled into a shared snapshot store on its own schedule, and the sales console only ever reads from that store, so a slow partner site or a rate-limited API never reaches the agent mid-call.
- Shared snapshot layer: One common snapshot shape, and all four sources publish into it. The read path treats a live database read, a daily API sweep, and a scraped page exactly the same.
- Honest-visitor scraping pipeline: For the carrier with no trade API, the scraper shows up as an honest, identifiable visitor, no borrowed credentials, no impersonating a logged-in session. It runs behind a residential-proxy pool with deliberate pacing, and there is a written escalation ladder for if the site's defenses tighten.
- Three-tier hotel class matching: Internal and reseller room counts get reconciled against the trip's actual package class, with a fallback ladder down to showing only the exact room on the itinerary when the booked class falls outside the package entirely.
- Isolated ingestion, pre-fetch only: Every external call, scrape, or partner API runs in its own deployable unit outside the core request path. The agent console never waits on a live fetch.
- Manual override as a breakglass path: Operators can upload a spreadsheet that overrides any automated feed. Recovery from an outage does not wait on an engineer.
- Three-tier failure signal model: Monitoring answers three separate questions: is the feed alive, did it run cleanly, does the data look right, folded into the operator dashboard the team already uses.
Technology Stack
| Category | Technology |
|---|---|
| Integration | Shared snapshot merge layer |
| Integration | Residential-proxy scraping pipeline |
| Integration | Partner API client (bearer token auth) |
| Architecture | Client-side parallel query merge |
| Infrastructure | Three-tier failure detection |
| Platform | Admin override console |
- Zero Live External Calls on the Sales Hot Path: The agent console makes 0 live external calls. Every read hits a pre-fetched snapshot, so a slow partner site never reaches a call in progress.
- Worst-Case Staleness Bounded to Under 20 Minutes: Even the highest-traffic feed refreshes on a 20-minute cadence, capping worst-case data staleness across all four sources.
- Four Systems Collapsed Into One Panel: Agents no longer know or care which of the four sources answered their question. There is just one answer, on one screen.
- Full Build Delivered in 18 Engineering Weeks: The merge layer, scraping pipeline, partner integration, and admin tooling shipped across roughly 10 calendar weeks of build time and 18 weeks of total engineering effort.
- Running Cost Held to About $90 a Month: The entire system, snapshot store, scraper, partner integration, and monitoring runs for about $90 a month all-in.
“Our agents used to disappear mid-call to check three other systems before they could confirm a date. Now the answer is just there, the moment they open the itinerary.”
– Head of Sales Operations, Travel & Hospitality
Before this project, confirming a single itinerary meant an agent manually checking four disconnected sources mid-call, with no way to know if the number they found was even current. Ksolves replaced that with one pre-fetched panel: agents get an instant, always-current answer, and the sales console never touches a live external source directly.
Zero live external calls now sit on the sales hot path. Worst-case data staleness across all four sources is bounded to under 20 minutes. And because the whole thing is built on a shared snapshot shape rather than four bespoke integrations, adding a fifth source, another carrier or reseller, will not require touching the read path agents already rely on.
That last part matters more than it might first appear. The business can absorb a partner changing its site or its terms without that instability ever reaching a sales call, because the scraping and partner-API risk sits fully isolated from the core platform.
Juggling Multiple Inventory Systems on Every Sales Call?
