Systems Thinking
Changes propagate through connected components. Change a price and it reaches cart, checkout, order history and refunds — so where should price be captured, and who owns it?
Change a product's price and the change reaches the cart, checkout, order history and refunds. Following one fact through every component that reads it reveals where the fact should be captured — and it is rarely where the reflex puts it.
Every component that reads a fact is a component the change must reach. Counting the readers, and the hops between writer and reader, tells you what a change costs and where it will be wrong — before it is made.
The current price of a product and the price a customer paid are two different facts with two different owners. Naming the source of truth for each fact — and noticing when one fact is actually two — is how the same number stops appearing in two versions.
For each piece of information in the system, one component should be allowed to change it and everyone else should ask. Assigning an owner to every fact — cart contents, stock, payment status, read state — is how a system stays consistent without a coordinator.
The payment provider, the email sender, object storage and the shipping carrier are not part of the store. Drawing the boundary — what we control, what we merely call — is the first step of every design, because everything outside the line can fail without asking us.
Everything outside the line can fail, can be slow, can change and can rate-limit — and will, on a schedule you do not control. For each crossing, deciding what the store does in each of those four cases is design work, not error handling.