Architectural Properties of an Enterprise Application

In this article I will discuss about four Architectural Properties that are important for an Enterprise Application. I will highlight the importance of each property and how all of them are needed for an Enterprise Application.

Reliability: Reliability of an Application makes sure that the Application will provide consistent output based on the functional SLA’s that have been set.

e.g. Reliability of a wrist watch is to tell the accurate time always so that we can rely on the watch.

Reliability of an ‘Addition API’ that returns addition of two input numbers is that it will continue to give sum of the input numbers in consistent manner at all times even at peak load.

Reliability of a Relational Database means that it will continue to support ACID transactions even at peak load or even if more database nodes are added in database system.

So, Reliability of an Application essentially means that we can rely on it to give consistent results.

Availability: Availability of an Application is to be available at all times for incoming client requests even if one part of the Application goes down.

Availability is achieved using redundancy. By providing redundant server components, we make sure a part failure of a system does not affect the Availability of the system. Availability can be provided using active-passive and active-active architecture. In active-passive configuration, redundant /duplicate server component is deployed in standby mode and comes up when first active server component goes down. In case of active-active configuration, both server components are always up and when one component goes down, second component is there to server incoming client request.

Service interruption in case of active-active is minimum.

Fault Tolerance: Fault Tolerance compliments High Availability by being able to detect a system failure and transparently route the ongoing client requests to second healthy server node. So, zero client requests are impacted as the ongoing requests on the server which has faulted are also migrated to healthy server node. Of course this comes with extra cost to be able to detect the failure and migrate the load.

Scalability: Scalability of an Application is being able to serve the requests even when the load becomes very high. e.g. if a web application (to book tickets) is serving 500 concurrent users and is also able to work well with same response time for 500 million users it means the architecture of this application is scalable.

A typical Web Application which uses stateless architecture in the front end layer and a single region relational database at the data layer might not be scalable beyond a capacity as relational databases can only afford vertical scaling which has a capacity limit that one can exhaust. So though web layer can be horizontally scaled (even across locations) to any level but database layer is limited to vertical scaling limits of hardware at one location.(please do note that adding more database nodes in a shared disk database system do have an overhead on performance)

Now looking at the bigger picture, an Application may provide high availability and scalability but if it is not reliable, it is of no use. Imagine a banking application that provide high availability and high scalability but if it does not support consistent ACID transactions at high load, the application will not be successful.

An Application which is Highly Available but not Fault Tolerant will have some users with a bad experience as they would need to login again. Similarly, an application which is highly available and reliable but if starts screaming at high load with high load time/bad user experience of its web pages, it is not a desirable architecture.

So, in summary we need all of these 4 architectural properties for an enterprise application.