You don't necessarily need to build a distributed system to solve that problem. You could have an entirely separate centralized system which serves that region.
Unless you can make the two systems independent, it's distributed. For most applications like shopping, for example, you must have a eventually centralized database. If you have multiple centralized databases that must talk to each other, guess what, that's a distributed system.
If those multiple centralized databases handle non-overlapping concerns, it is not different than a single centralized server. Still a distributed system (client & server) of course, but that doesn't seem to be what people in this subthread are getting at.
An example of this kind of architecture would be to have server per country, where each database synchronously maintains inventory for the warehouses it is (uniquely!) responsible for.
If you now have many centralized systems... Don't you by definition have a distributed system?
Not in the sense that it matters to the customer.
You can have a customer connected to their local centralised shipping centre before confirming an order, so every customer who would be supplied from that centre is seeing the same real-time stock indication. If supplies of a product the customer is trying to order are low, you can manage expectations accurately, for example warning that the product is almost out of stock and saying you'll confirm the order within 15 minutes to deal with races, or providing a "we're holding this for you, but you need to complete your purchase within X minutes to guarantee it" system as many on-line event ticket systems do.
You can certainly have distributed infrastructure and logistics behind those local centralised shipping centres. You still have to physically transport the products there from your manufacturing facilities or suppliers. You still have to do marketing and PR. You still have to do your corporate accounts. However, you have 100% isolated your customers from the distributed aspects of your business, and those aren't going to result in a bad experience for a real life customer just because a delivery driver was stuck in traffic for 10 minutes and arrived later than scheduled with the new stock.
On the contrary of your belief,
I think your point plainly shows the author point of view
"distributed systems are a UX problem".
Or in other words a "business problem"
which cannot be solved only at the system level.
In your case you choose to minimise the risk of not fulfilling an order
by having a shop per stock.
This is a perfectly acceptable choice.
But there are other options which maximise sales opportunities
at the price of more risks, which have to be compensated in turn
by a whole chain of business/logistic/human/technical processes and mechanisms.
I wasn't aware that I was disagreeing with the original author. I think the point made by the article here is a valid and useful one. I'm just agreeing with an earlier poster that one possible strategy for dealing with this issue is to change which parts of the system are, effectively, distributed.
If the customer is directly exposed to a distributed ordering system, then it is inevitable that they will sometimes see symptoms of the kinds of technical problems we've been discussing. However you dress it up, that is never going to give the ideal buying experience to all of your customers all of the time.
On the other hand, if you can shift the distribution mechanisms behind the scenes, you still have to deal with similar sorts of problems, but only internally. Your staff can be trained to understand and deal with the kinds of race conditions and scheduling conflicts that might arise, and they aren't going to get upset and take their business elsewhere the way an angry customer might when those things happen.
I better understand now the distinction you make
between a distributed system
and a distributed system directly exposed to the customer.
The former is a fact we have to cope with,
while the latter is definitely something we can and have to minimize.
