Abandoned carts have many well-known culprits: surprise shipping, forced login, long forms. There is one that rarely shows up in the report, because it is not a page or a field: it is the distance between the customer and the server.
Every 100ms of extra latency at checkout is friction at the exact moment the customer decided to buy and just wants to finish. And distance is an architecture decision, not a fate.
The math of the slow checkout
A modern checkout is not one call: it is a choreography. Session, catalog, cart, antifraud, gateway, invoice issuance, confirmation. Dozens of requests between the "checkout" click and the thank-you page.
Now add geography: a US server responds in about 120ms to a São Paulo user; served from Brazil, the response arrives in 4ms. That is over 100ms of travel on each of the journey’s dozens of calls. Multiplied, it becomes whole seconds between the tap and the screen’s reaction. That is exactly the interval where the restless phone switches apps and the sale dies without leaving a log.
We covered the full ruler in VPS in Brazil: 4ms latency and the cost of hosting far away. In e-commerce, the same ruler weighs more, because every millisecond sits downstream of a purchase intent.
Pix changed the ruler again
Cards taught Brazilians to wait for processing. Pix promises instantaneity, and customers demand it on screen: the payment is real-time, and the whole chain (store, gateway, PSP, Central Bank network) adds its latencies until confirmation appears.
In a flow sold as instant, every extra millisecond is direct friction on a product whose proposition is frictionless. Add the risk and antifraud centers that also talk to checkout, and the latency math of Brazilian e-commerce gets denser than any asynchronous market’s.
What transactional architecture solves
Latency is half the equation; the other half is peak. Black Friday is approaching, and it is every store’s final exam: multiplied traffic, complete journeys, every call transactional.
High-scale transactional architecture exists for that exam: separating synchronous from asynchronous (payment answers, analytics waits), giving checkout dedicated capacity, queueing what can wait, degrading gracefully when a link fails, and scaling automatically with demand. None of this is exotic; it is the minimum package to turn peak into revenue instead of a headline.
And the test matters as much as the design: hosting untested at peak is a promise, and Black Friday does not accept promises, it accepts a schedule of simulation, correction, retest, and change freeze.
The 30-days-before checklist
- Week 1: measure end-to-end latency per journey (not just the server) and map the slowest link.
- Week 2: load test with a real profile times a margin; fix whatever bottleneck appears.
- Week 3: retest, validate the plan B per link (gateway, antifraud), and rehearse rollback.
- Week 4: change freeze, journey monitoring in operation, and on-call defined.
Four weeks, one exam passed. The cost of skipping the checklist shows up in the first peak hour, with seasonality interest.
Conclusion
Latency never appears in the abandoned-cart report because it is not a page: it is the delay between intent and response, multiplied by every call in the journey.
The decision that eliminates it is architectural and geographic at once: a transactional checkout designed for peak, served close to the Brazilian customer, with data under LGPD and Pix answering at the speed Pix promises. Black Friday is weeks away; the migration is one sprint.