Hacker News Reader

Comment by tylertreat | Hacker News Reader

There seems to be a bit of confusion over just what exactly I'm trying to get at here. I'll be the first to admit, the article might not do it justice. This is a comment I posted on it which hopefully helps clarify:

The point is there are certain realities inherent in distributed systems which can’t be papered over, and those realities often manifest themselves at all levels in the stack. Sure, we can try to build abstractions which hide those problems, but they often leak or simply eschew the problems in dangerously subtle ways.

Frontend and UX folks need to understand what they are building on. They need to understand the potential pitfalls of these abstractions and why they are as such. Sometimes there is a good business case for apologizing, sometimes there’s not. These things are never black and white, but if everyone can understand how systems work, we can build better ones and make better choices.

View on HN

And my reply:

I agree that there are complexities (as you state, “certain realities”) inherent in distributed systems. If there is one thing I believe we could both agree upon is that distributed systems increase the surface area of complexity exponentially when compared to the relatively simpler stack of clients communicating with one system.

Failures in a distributed environment must be expected. Embraced even, since treating them as “an exception” is tantamount to the proverbial ostrich poking its head into the sand.

However, failure in a distributed system does not necessitate “Frontend and UX folks” having to address failures which are not directly a result of client communication with the next tier. For example, should the UX be prepared to handle when the primary provider of a service is down and fail over to a secondary system? If the service is the one which the client is directly interacting with, then likely that makes sense.

But what of the case when the primary system has issues interacting with its collaborators? Such as its persistent store. Or a strategic partner providing required functionality for the workflow. Is it your position that this type of failure be handled by the UX?

Why wouldn’t a server maintain separation of concerns and only communicate to a client when its options have been exhausted? IOW, why assume what “the other side of the connection” is going to do in order to satisfy a request placed on it?

In summary, my position is that when the collaborators in a distributed system have a well defined software contracts (protocol, expectations, etc.) and all parties adhere to them (without assumptions in implementation), then this allows the system(s) involved to provide resilience in depth. However, the fashionable trend of replicating a PowerBuilder environment does not lend itself to these separation of concerns.

Foisting complexity to either end of the spectrum is where truly nasty problems are bred.

In a distributed system, there is no "primary" system. All systems are distributed and decoupled. The UX sends a request and waits for a response that itself be composed of other requests and responses from multiple other systems. The failures have to be assumed and mitigated for at the UX level, not at some back-end level.

By "primary system", I meant the initial system(s) interacted with in a distributed environment. Assuming a connection based distributed model (e.g. TCP/IP), there is a system on the other end of the connection to which a client is communicating. Even for connectionless models, in my mind the "primary system" would be defined as the set of systems which could possibly respond to a client's request.

Perhaps the term "primary" is not the best fit for this role. It just seemed less verbose than saying something like "the set of systems for which a client is directly aware and may interact with."

As a UX person, I'm intrigued by this idea, but I would probably avoid creating situations where it is necessary to apologize. If you confirmed a flight, hotel and rental car, but then came back with a "Sorry!" later, that would be a negative experience for a user. They may have passed the confirmation on to others or set other plans in motion, which may also have to be "rolled back". You would need to compensate customers for the inconvenience.

The way to avoid that is to show requests in a pending state, but this has other implications. Users will want to continue to shop and to cancel pending requests, which might mean lost sales.

Generally it's more important to paper over the realities of a complicated system when you have a customer-facing self-service tool. Exposing those realities might create too much complexity for self-service, and you may need sales and service people to manage it. Basically you've built a travel agency instead of Expedia, which, again, is more costly.

Reply on news.ycombinator.com