Tax rates change annually and must apply from a specific date. How do you manage that across a dozen systems?

What is being tested

Whether you handle temporal validity and distribution, which is where reference data actually breaks.

The core requirement: effective dating

Never overwrite. Each rate carries a validity period, and a calculation uses the rate that applied at the transaction's date, not today's.

Overwriting silently rewrites history: a report re-run for last year produces different numbers than it did last year, and nobody can explain why. That is the failure that destroys trust in reporting, and it is caused by a single design decision.

The distribution model

A single owner and a single publication point. One system is authoritative; everything else consumes. This organisational decision resolves most of the problems.

Distributed, not queried. Reference data should be replicated locally — as a file, a cached dataset, a small local table — not fetched per request. It changes rarely and is needed constantly; a synchronous lookup makes the reference service a dependency of everything, and its availability becomes everyone's availability.

Versioned as a whole, so a system can state which version of the reference set it is using, and two systems producing different answers can be diagnosed in minutes.

Managing the change

Publish in advance with an effective date. The new rates are distributed weeks early and become active on the date. Systems pick up the change during a normal cycle rather than in a coordinated release.

Change managed like a release: notification, a lead time, and verification that consumers have picked it up — which is the step most often missing, and the reason a change lands unevenly.

Backward compatible by default. Add entries; deprecate rather than remove; never reuse a retired code, for the same reason a protobuf field number is never reused — old records would be silently reclassified.

Failure scenarios

• Overwritten in place, so historical reports change retroactively.
• Every system with its own copy, drifting, so the same transaction is taxed differently in two places.
• Fetched synchronously, making the reference service critical.
• No verification of uptake, so one system is still on last year's rates.
• No owner, so changes happen ad hoc.