Success of an application depends on its performance and its cost of maintenance. Interestingly both of these factors are largely influenced by the simplicity of the algorithm and it is also important to choose the right application layer for executing this algorithm. Often accessing and processing “data” plays the pivotal role in an application’s performance.  So we can say that writing simpler data access and process algorithm we can make an application faster and scalable. Needless to say that the application should also be free from contention and locks at runtime.

Here is an architecture to apply these principals in a traditional system built with Oracle and Java.

Lets talk about accessing data – Oracle provides one of the fastest way to access data. So as a principle we will always depend on Oracle technology for accessing data. We will use simple SQL, well-designed table, pinpointed index and partition to access this data in a very fast manner.  We will not write complicated SQL which may give inefficient and complex plan which will always be slower. We will segregate data from processing so that complexity of processing doesn’t make data access complex. A complex data access is a very slow process.

Lets talk about processing data – Java (or a comparative Language) is a very fast processing engine because they entirely work in memory. It can be multi-threaded to use all cores of the server. It provides functional and object oriented paradigm to write complicated algorithm in a simple way. In-memory (soft) data structures can be built to suit the exact need of your algorithm so that finding data will be fast. This will be harder to achieve in a hard data structure like database index. So as a principle we will push execution of algorithm into Java.

Lets talk about contention and locks – Adopt immutability to protect the application from locks. Find a natural boundary/partition of data, which can be processed independently from each other. The more granular this partition is the faster your application will be. With immutable code, an in-memory process can be largely free from any contentions and locks. Whereas data access can not be as contention free because logically granular data may be sharing the same disk location and hence bottlenecked due to things like hot blocks, segment contention etc. So to build a contention free application we will prefer Java (or a comparative language) over a complicated SQL.

A real life application built on these principles yielded 10 times better performance as compared to a system built using complicated SQL.