A travel platform's currency, tax and geography reference data changes over time. Bookings must be reproducible years later. What does the reference data architecture need?

The requirement that drives the design

A booking must be explicable using the reference data as it was at the time of booking, not as it is now. A tax rate that changed last quarter must not silently restate a booking from before the change.

That makes reference data bitemporal: each record has a validity period in the real world and a period during which the system believed it. The second dimension exists because corrections happen — a rate entered wrongly and fixed later has a real-world validity that differs from when the system knew about it.

What the architecture needs

• Versioned reference records with validity intervals, so a lookup is by key and date.
• A [[temporal-join]] on the transaction's effective date, not the current value. This is where most reproducibility defects originate, and they are silent.
• Distribution to consumers with the version identifier attached, so a service can state which reference version it used.
• A change process with lead time, because a reference change affects pricing, tax and display everywhere at once.
• Explicit handling of retroactive corrections, including what happens to transactions already processed — the data can be corrected, the emails already sent cannot.

The failure that recurs

Reference data stored as current-value-only. Once the history is gone, reproducibility is not recoverable by any later effort, and the discovery usually happens during an audit. The decision to retain history has to be made before anyone needs it.