A feature flag controls a pricing rule. Finance asks who changed it, when, what the previous value was, and which orders were priced under the new value. Walk me through what that requirement does to the design of your flag system.

What the interviewer is testing

Whether you notice that this is no longer a feature flag. It is business configuration with financial consequence, and the question has just imposed a different set of properties: authorisation, an immutable change history, retention measured in years — 7 years is the common answer in finance — and the ability to state the value in effect at a past instant and defend it, because a number that cannot be defended is a restatement waiting to happen.

A candidate who answers "our flag platform has an audit log" has missed the hard half.

The clarifying questions that change the answer

• Is the requirement to explain a change, or to reprice an order? "Who changed it" is an audit log. "Which orders were priced under the new value" is reconstruction, and it is much harder.
• How is the flag evaluated? Once per session, once per request, or cached at instance startup? Each gives a different answer to when the change took effect, and two of them make timestamps meaningless.
• How long must the history be kept? If the answer is seven years, no general-purpose flag platform is the right home for it.

A strong answer's arc

Classify the flags first. Release toggles are short-lived, engineering-owned and deleted after rollout. Operational switches — kill switches, degradation levers — are owned by whoever is on call. Business configuration is a third thing with a third set of rules. Only the first should be flippable by anyone with console access, and the failure in most estates is that all three live in one system with one permission model.

For the pricing value specifically:

• An append-only change log with actor, timestamp, previous value, new value and a reason, plus approval by a second person for this class of change.
• The effective value recorded on the artefact. The order stores the price and the identifier of the pricing configuration version that produced it.

That second point is the load-bearing one. Do not plan to reconstruct pricing by replaying flag history against order timestamps. A flag flipped at 14:00 reaches instances in production over anything from 30 seconds to 5 minutes depending on cache expiry and evaluation frequency, so for every order near the boundary the reconstruction is a guess, and a guess is not evidence. Recording the version on the order makes the question a join instead of an argument.

Common weak answers

• "The flag service already logs changes." It logs changes to the flag. Finance asked about orders, and the mapping between them runs through propagation delay and caching that the log knows nothing about.
• "We will query the flag history by timestamp." This fails at exactly the orders anyone will ever dispute — the ones near the change.
• "Add an approval step and we are done." Approval satisfies the authorisation half and none of the reconstruction half.

What a strong answer adds

This requirement is the signal to move the value out of the flag system entirely, into versioned pricing configuration with a release process, a schema, and a version identifier that travels onto every priced order. Flags stay for what they are genuinely good at: short-lived rollout control where the cost of being wrong is a rollback rather than a restatement. The rule: choose the flag system when the worst outcome is a bad release, and versioned configuration when the worst outcome is a number someone has to defend. When not to split them: an internal tool with no financial or regulatory consequence, where a single flag store and a change log is proportionate.

The organisational half matters too: whoever answers the finance question owns the retention of that history for as long as the finance function needs it, which is years. Flag platforms are built for change velocity, not for evidence, and asking one to be a system of record is how a tooling decision becomes an audit finding.