A wrong currency in a quote response does not necessarily mean the currency calculation is wrong. The calculation may have received another request's currency. That can happen when a web application keeps a mutable “current buyer” object outside the request and reads it again after waiting for a database or external service.

This is a specific engineering concern for teams maintaining an HTTP enquiry or quotation application, including overseas teams working with a Chinese manufacturer's product data. It is not a reason for businesses without such an application to rebuild their enquiry process.

AWS's October 12 introduction of Lambda Web Functions makes the review timely for teams evaluating that deployment option. The service supports standard HTTP applications and multiple concurrent requests in one execution environment. Before changing the deployment, check whether the application assumes that one environment means one unfinished business request at a time.

The waiting interval is where the assumption breaks

Consider a request that stores its selected currency globally, then waits for product information. While it is waiting, another request can update the same global object. When the first request resumes, its own local input still represents the first buyer, but the shared “current currency” may now represent the second. Reading the shared value introduces the mismatch.

JavaScript executing one piece of code at a time does not remove this possibility. Asynchronous work allows several request lifecycles to be in progress together, even when their JavaScript steps are interleaved rather than executed simultaneously. The vulnerable interval is the time between writing a shared value and reading it again, not just the instant when an assignment runs.

Buyer identity, selected model, quantity, currency and applicable quotation conditions belong to the request that supplied them. Pass those values through local variables or an explicit request scope, so later processing uses that request's copy. A downstream function should not have to discover the buyer by consulting a mutable process-wide “current” object.

This does not justify banning all shared data. Read-only field definitions or versioned public product configuration may be suitable for reuse. A cache needs a more careful distinction: public product information and buyer-specific quotation conditions are not equivalent. A cache keyed only by model can still mix business contexts if its value includes conditions that vary by buyer. Fixing a global variable while retaining an incomplete cache key leaves another route to the same symptom.

Test overlapping lifecycles, not just correct examples

An application can pass a series of sequential tests and still have this problem. Each request finishes before the next changes the global state, so the vulnerable interval is never exercised. A more useful review traces a real path from input, through waits and calculations, to the response, marking shared reads and writes along that path.

Use synthetic requests with different non-sensitive parameters and let their processing overlap. Match each response back to its own input: model, currency and selected conditions should not drift between requests. Give the test a bounded scope and identifiable requests. There is no need to flood a production endpoint, record private buyer data or expose commercial quotation details in logs to observe whether values remain associated correctly.

If a mismatch appears, preserve competing explanations. Shared-memory overwriting, an incomplete cache key and incorrect downstream data can look similar in the final response. The approach discussed in keeping incident explanations in separate branches is relevant here: seek evidence that distinguishes the causes instead of treating the first plausible explanation as established.

Request isolation is also separate from persistence. A quotation draft or operation state needed after the response should not depend solely on the process remaining alive or the next request reaching the same environment. Durable storage answers whether the business record survives. Request scoping answers whether one request reads another's temporary context. Neither repair substitutes for the other.

The AWS announcement has runtime and regional conditions that require a separate deployment assessment. The immediate code review is smaller: locate mutable buyer-specific state, follow it across asynchronous waits and confirm it stays attached to the request that owns it. That requirement can be tested before any hosting decision is made.

Sources