How Do Schedule Changes Affect Cached Results?
From the earlier reference collection. Read the current software blog.
Cache schedule answers with both the feed version and the service date so refreshed data and date-specific service rules do not collide.
Treat a timetable answer as contextual
A cached result such as “the next trip is at 08:10” depends on more than a route. It can depend on which feed version was read, which service date is being queried, and which calendar exceptions apply. GTFS defines a dataset as a complete set of files and describes a new dataset version when the data changes. [GTFS schedule reference](https://gtfs.org/documentation/schedule/reference/)
A cache key that includes only route and stop can therefore serve yesterday’s answer after a schedule update or reuse a weekday answer for a holiday. Include a stable feed identifier or version marker and the service date in the key, alongside the query dimensions that shape the result.
Choose a version marker
If the publisher provides a version value, use it consistently. Otherwise, derive a fingerprint from the retrieved dataset or its constituent files, such as a content hash, and retain the retrieval time as metadata. Do not assume that a URL alone identifies an immutable feed: the same address may serve changed content later.
For example, a query key could conceptually combine agency, feed fingerprint, service date, route, and stop. When a new feed is downloaded, its fingerprint changes and old entries become unreachable for new lookups. This avoids having to identify every affected trip by hand.
Expire data with its meaning
Set an expiration appropriate to the publisher’s expected update pattern and the product’s tolerance for stale schedules. A cached static timetable may remain useful for a defined period, but a successful feed refresh should trigger a new version namespace. If a refresh fails, preserve the prior data only with clear freshness metadata instead of presenting it as current without qualification.
Service-date boundaries deserve care for overnight trips. A trip selected by Friday’s service pattern may have an event after midnight Saturday. Cache that answer under the service date used to select the trip, while retaining the event’s resolved calendar date in the result.
Make invalidation observable
Record the feed fingerprint, retrieval time, and service date with each result or in diagnostic logs. When users report a discrepancy, those fields reveal whether the application used an old dataset, the wrong date, or the wrong exception pattern. Avoid logging unnecessary personal data when a query can be diagnosed from schedule identifiers alone.
A good cache policy combines versioned keys with reasonable expiration and a visible “data last retrieved” note. That gives schedule readers predictable results while allowing an operator to explain why a previously shown itinerary changed after a feed update.