Running this argument in the other direction: if you want an uncompromised user experience, you should use or build a centralized system rather than a distributed one.
Reading your comment made me think of Apple and Microsoft. Microsoft makes an operating system that runs on a distributed hardware ecosystem and they have the unenviable task of making the user with crappy (but cheap) hardware actually work. Apple is completely vertically integrated, so they can make sure everything works smoothly in their vision, but you only get Apple's vision.
Then you have Linux, which is a distributed software ecosystem on top of a distributed hardware ecosystem. UX is terrible, but flexibility is through the roof. You can pretty much have exactly what you want, although you might have to do parts of it yourself.
UX doesn't have to be terrible. It's just a long twisty maze of interlocking decisions. Depends on the U, too - I feel better with command line tool output and filters than with fancy GUI furniture.
Depends on what you want out of your UI. I ran Linux for years and years on my laptops. But getting a consistent look was difficult: Firefox, OpenOffice (at the time), Emacs, Inkscape, Gimp, the KDE CD burner I used, etc. all had different toolkits so theming never really looked right. Every time I upgraded Ubuntu something else broke: first sleep, then wifi, then audio (pulseaudio and jack, grrr). Getting on the network after an install was usually a bit of work. Maybe DHCP worked fine, ... and maybe it didn't. Configuring X (resolution, mousewheel, etc.) was a chore, although I think that's no longer necessary. I never did get my USB thumb drives to automount, although I heard tell it was possible.
That long, twisty maze of interlocking decisions, and the fact that every decision could and did go wrong, usually necessitating several hours of troubleshooting, that's bad UX.
Don't get me wrong, I love the idea of Linux. But Mac OS X is the real Unix on the Desktop.
Yeah, my X on Linux is wonderful, but pretty far from what is offered elsewhere (or typical on Linux), and I have no confidence it would be a good X for any particular other U.
Even an app for your phone that communicates with a server is a distributed system.
Even a programm performing a simple read/write operation on the file_system_ is part of a distributed system. Handling exceptions is precisely a way to deal with the uncertainty of these two systems working together.
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.
