Short answer: give each browser fetch a request ID, carry it to the backend in a standard HTTP header, and emit that same ID in structured logs on both sides.
Keep the pricing decision itself behind a flag with an explicit evaluation ID, so a rollback can be verified instead of guessed.
The browser is the first audit surface Rolling out a new pricing rule in an edtech app sounds like a feature-flag task.
Operationally, it is a tracing problem with money attached.
A student sees a price in the browser, the frontend calls the checkout backend, and the backend evaluates a flag before writing an order.
When those events cannot be joined, a rollback turns into a debate about which request produced which price.
I've been paged for missed jobs and duplicate deliveries.
The same failure pattern appears here: a dashboard says the system is healthy, but the individual request that matters is hard to reconstruct.
A request ID doesn't prove that a price was correct.
It makes the evidence joinable.
The smallest useful contract is straightforward: The browser creates a non-secret request ID for each outbound fetch.
The ID travels in (or the equivalent header chosen by the team).
The server validates or replaces malformed values, then logs the accepted value.
Every log record for the request includes the ID, route, outcome, and duration.
A separate flag-evaluation ID identifies the pricing decision and its rule version.
Don't put a user email, token, or price in the request ID.
It's a correlation key, not an authorization mechanism or a business record.
How should frontend and backend logs correlate a browser fetch request ID?
The browser and server need a shared boundary, not a shared logging library.
For a JavaScript or Node.js application, the fetch wrapper should generate an ID before sending the request and attach it to the headers.
The Node.js service should read that header at the HTTP edge, bind it to request context, and include it in every subsequent log event.
The exact language is secondary; the propagation rule is the important part.
Here is the server-side shape in Go.
It accepts a caller-provided ID only after checking its size and character set.
In a deployment with a trusted gateway, the gateway may establish the value instead; the application still needs a clear ownership rule so two layers do not silently disagree.
The response header matters during a rollback investigation.
A support engineer can copy the ID from a browser network record, then search server logs without asking the customer to repeat a purchase.
The response should not expose internal flag rules or other sensitive diagnostic fields.
The example deliberately keeps the flag decision separate from the transport ID.
One request can make several internal calls; one pricing decision can be recorded once with a stable evaluation ID.
If those two identifiers are conflated, retries and fan-out become difficult to interpret.
The event contract is the durable boundary A useful event is small enough to query and rich enough to explain a decision.
At minimum, record the request ID, timestamp, service or browser component, route name, status class, duration, and a result category.
For the pricing path, add the flag key, evaluation ID, rule version, cohort label, and whether the response was a quote or a committed order.
Hash or omit identifiers that are not needed for the investigation.
Log the transition that changes operational meaning.
A quote viewed in the browser is not an order committed by the backend.
Recording both under one request ID does not make them the same event; it only lets the investigator see their relationship.
The four golden signals are a useful starting lens: latency, traffic, errors, and saturation.
Correlation extends that lens from aggregate health to one transaction.
For example, a low error rate can coexist with a bad flag rule if the requests return successful responses with an incorrect decision.
That is why a rollback monitor should compa