The problem was operational latency
Goa pricing had a specialised manual path. Someone prepared and downloaded a file, moved it to the correct machine, changed the input used by a publisher and ran the process. The calculation could be right while the operating model remained fragile: knowledge lived with a few people, validation was inconsistent and an approved change could take weeks to reach the platform.
I treated this as a product-system problem rather than merely writing a cron. The goal was a maintained source of truth, automatic calculation, a safe relationship with the rest of India's base-fare pipeline, observable fallbacks and one controlled way to handle an urgent exception.
This article is intentionally public-safe. It explains the engineering decisions and lessons without exposing customer data, proprietary prompts, internal identifiers, operational commands or confidential decision thresholds.
- SOURCESRead the latest eligible pricing and demand inputs
- RESOLVEApply the most specific valid source and fallback
- CALCULATEGenerate Goa base fare under common guardrails
- MERGECombine with the normal national publication frame
- PUBLISHRefresh on the regular service cadence
Make Goa special in calculation, not in delivery
Goa required its own calculation because its fleet and commercial inputs did not fit the default path cleanly. I kept that difference explicit inside the base-fare service, then normalised the result to the same publication schema as every other market. The Goa frame and the rest-of-India frame were merged before the common publisher.
That boundary prevented a second end-to-end pricing stack. Downstream consumers received the same contract, audit behaviour and cadence regardless of which calculation produced the row. The specialised logic stayed local to the place where it was actually necessary.
Design the fallback hierarchy before the happy path
The inputs did not all have equal coverage or freshness, so the service resolved them in an explicit order: prefer the most specific current signal, fall back to a broader maintained value when coverage was missing, and retain the previous safe state rather than manufacture a zero. Each resolved row carried enough provenance to explain which path won.
Fallbacks were validated as normal production behaviour. I measured how often each branch was used, rejected invalid or non-positive results and made absence visible in logs and reconciliation. A fallback that is invisible becomes permanent technical debt; a fallback with coverage and ownership is a controlled reliability feature.
Automation still needs an emergency door
The normal job refreshed maintained source state and the regular incremental base-fare cycle published eligible changes. For a time-sensitive authorised correction, I kept a narrow ad-hoc interface that accepted the asset group and revised hourly value, passed through the same validation and left an auditable record.
The emergency path did not replace automation. It was deliberately smaller than the old file workflow, explicit about its target and unsuitable for broad routine changes. That balance matters: removing every manual control makes recovery dangerous, but allowing the manual path to remain easiest guarantees the automation will decay.
Validation and operating ownership
I reconciled source coverage, resolved values, generated fares, merge counts and publication results. Tests covered missing sources, stale data, invalid values, duplicate keys, unchanged fares and publisher failure. Runbooks described the normal schedule, verification query, logs, fallback meaning and the approval needed for an exceptional correction.
The service also separated source refresh from fare publication. That made a delay diagnosable: was the maintained source stale, did calculation fail, or did the publisher reject the output? One end-to-end success flag would have hidden those different recovery actions.
Result
The Goa refresh cycle moved from weeks to under 30 minutes. More importantly, the result no longer depended on remembering a file ritual. It became part of the maintained pricing system with shared guardrails, traceable source choice and a documented recovery path.
Automation is not the absence of a human. It is the conversion of human judgement into explicit inputs, ownership, validation and safe exceptions. The speed improvement was the visible outcome; the real gain was making the process repeatable.