Application Design in a High Availability Environment

[MCWebsite.Staff]

** This thread discusses the article: Application Design in a High Availability Environment **
** This thread discusses the Content article: Application Design in a High Availability Environment **
0

[bharder@nlrha.ab.ca]

Application Design in a High Availability Environment

** This thread discusses the article: Application Design in a High Availability Environment **
Good article. You thought of some sources of error that I didn't think of. Then again, some of these sources are not applicable to the environment I work in. The rules I follow are: 1). Code defensively. Assumptions are a big source of problems; 2). Systems cannot be designed without assumptions. Document what those assumptions are; 3). Error check everything, even if you don't see how it could possibly fail or be "wrong"; 4). Good internal change documentation makes a big difference. Document who did what, and when; 5). Leave the client in control. I've noted a tendancy in critical environments, in certain systems, to code too strictly. These systems work around a model that a function has to work 100% or the function fails completely (with an error message of course). While this is appropriate in data updating functions, it's often overkill elsewhere. In reporting environments, partial information is often preferable to no information. The system is smoother and more responsive that way. Remember that not receiving an answer is a "failure" from the client's perspective. Don't allow fundamentally compromised information out, of course. I'm just saying that minor errors on a report are rarely fundamental. The client can judge whether they care about the minor errors. If so, they'll re-run the report.