ROBUST MVC APPLICATION — THE BANKING ARCHITECTURE
By: Shivendra Pratap Kushwaha
Tags: Financial Services, Architecture, Mvc, Mvc Frameworks, Banking

Ever thought how many users would be using banking applications at some instant? We use it for payments, transfer funds, loan, credit card, travel, transport, business and much more. And all of these are for one person. There can be hundreds or thousands of uses and millions of users. So how does all this happen and how such a robust application is created to handle such heavy traffic? All these questions might come to your mind. So let’s discuss it in the simplest and understandable way.

The MVC Framework :

The banking application consists of three main components, benchmarked to provide the best performance in itself. These three components are designed for some specific task. These three tasks are moulded into MVC framework. The task consists of :

Creating the request (View) Route the request (Controller) Process the request (Model)

As the simplest flow, User will create a request by submitting to the browser or any of the channel(view), the request is sent to controller, controller will divert the request to model for further processing based on the type of request. The model after processing the request, creates the response and sends it back to the controller and the controller again sends it back to view. And that complete the lifecycle of a single transaction.

Technical Aspects :

Now comes the most essential part. How do all these components interact with each other? How does the controller react to all these requests simultaneously? Well, let’s divide it into four parts.

Request/Response from View to Controller : This is done with the help of Socket Programming. Here, the view acts as a client and controller acts as a server. The connection can be short or long based on functional behaviour. Processing in controller : As there can be multiple channels sending requests, the controller uses multi-threading to accept and route the requests to the model simultaneously without any lag. Request/Response from Controller to Model : Controller and model being in the same machine allows to use Inter Process Communication (IPC) as a mode to transfer the request to the model. The request is sent to the Queue and received by the model from the Queue for further processing. Processing in Model : Model again forks as soon as it gets the request and get ready to receive another request. This again helps the application to start processing the request without any lag.

Functional Behaviour :

But how are all these requests processed? As mentioned above, each Queue is related to a specific module of bank(DEP, LON, CIF, TFIN, etc.). The request will be sent to the specific module/Queue as decided by the controller based on the request data. As soon as it receives the request, it forks and creates a child process. Each child process will start the processing based on the business logic and various business functionalities will be performed. After the processing model will create a response to be sent back to the controller.

Only this much? Actually, NO. That’s just architecture and how it works. But there is a whole sea of technicalities and functionalities working under such a great, huge and robust application. Want to dig more into it? Think!! Even after having so many requests per second, how much time does it take for you to do any of the transactions?