Contact Information

  • AUTHOR Yogesh Shinde
  • PUBLISHED ON May 25, 2021

 

Architect to manage Billions of Transactions

 

A leading online payments service provider handles thousands of payment requests over a period of a day. As a greater number of bank account holders are preferring the online mode, the payment gateway needed more processing time due to increased traffic. This resulted in more failed transactions and dissatisfaction among the end users.

Requirements

Deployment Scalability: Our customer basically needed to maintain a smooth payment experience for the end users. As the end user traffic would increase during certain duration of the day, the gateway would need to step up the performance to address the increasing load. On the contrary, once the traffic would reduce, the gateway would need to step-back and go back to the default transaction capacity. Customer needed a deployment environment that would intelligently step-up and step-down to maintain best response time at any hour of the day.

 

Transaction Processing Time: Customer’s existing environment was designed to handle 150 transactions per second, which would take average 10-30 seconds for every transaction. With increase in traffic, the processing time would stretch to 1 minute or more. Customer’s existing deployment environment was not flexible to step-up and step-down the processing capacity based on the traffic patterns.

Solution

Kubernetes-based deployment architecture: provided the flexibility of automatically scaling up and down, based on the traffic. Architected the solution based on Kubernetes as the system provided a facility to configure auto scaling of the deployment environment based on criteria such as number of transactions, memory utilization and the number of users. Once configured, the system would evaluate the traffic based on pre-defined parameters and make changes to the deployment automatically.

Kubernetes-based, AWS-enabled horizontal scaling: provided scalability to address the requirement of increased traffic. As the traffic would increase during certain time of the day, Kubernetes architecture would create clones of the payment solution deployed on an application server. These clones along with the original application server would in turn balance the transaction load among themselves. This facility would boost up the processing capacity from 150 transactions per second in the default state to 5000 transactions per second during the peak traffic hours.

AWS-based load balancing: helped in monitoring the system performance and kept a tab on the total cost of deployment. As the customer needs to pay hourly premium fee for the Kubernetes based deployment, it was important to ensure that the facility was utilized only when needed and disabled when unnecessary. The load balancers and automated scaling-down helped in achieving this goal. The system would quickly create more clones and maintain the scaled-up deployment as the load would increase during the peak hours. On the other hand, when the traffic would dwindle down, the clones would be disabled, and the system would default back to the single application server. Thus, the system would operate at the minimum cost for the most part of the day.

Transformation of the premise-based monolithic architecture to cloud-based, modular, microservice-based architecture increased the maintainability and portability of the solution.

Post Comments

Leave a Reply