I was impressed on a project a few years ago (CommSee Case Study) that the architecture allowed as much of the application to run (albeit in a limited fashion) even when the database server was in-accessible for some reason (other services relying on web-services still operated); They called it Limited Service Mode. For real-time customer facing systems, there must be some functionality that is available when a resource has failed. It is all too easy to design a system that fails completely leaving end-users with no sign-of-life when operating conditions degrade.
What are some of the aspects to consider when desiging in this sort of feature:
- Offline Mode - Can the application be built to operate offline and synchronize when network connection of database functionality resumes?
- If data is retrieved and sent to web-services, can the server-side start queuing these requests, and catch-up when the DB or SOA bus is restored?
- If it is a public website, at least the home page and contact us page should display, even if it is only in one language (hopefully the language which gets the majority of hits)
- Not all actions should be allowed; If data or financial loss could occur, then that feature isn't a candidate for use when in limited functionality mode
It is an interesting thought experiment; When you are writing your next feature have a think about how you could improve its end-user experience in the case of a network, database or other failure mode.
Troy.