//

Rather than on-boarding a giant do-everything developer ship, it is better to use a medium-sized steamer with a fast engine

Mypoolin is a social payments platform that allows users to perform two tasks seamlessly.

• Splitting and settling bills for daily use like dining, parties, lunch.
• Planning and paying with friends for movies, events, gifts and more.

By virtue of the nature of our application and user flow, the app consists of a four-part transaction journey  —  discovery (for planning), creating a group, chatting and paying as well as redeeming the collected amount.

Over the course of the transaction, there are multiple touch points for a user. They are facilitated in a manner that creates a system comparable to a river delta. The tributaries that fill into the main river are our multiple third-party API interactions (recommendation listings, chatting, payments) that help people sail through the app in a matter of seconds.

Also Read: Why brick-and-mortar businesses have an advantage in the digital economy

In such an app flow, the speed and resilience of the system are of prime significance for our company.

The goal is that each touch point experience should be delivered with optimum speed and reliability. Hence, when we decided to shift from our existing stack to a reasonably better one, we were visibly excited.

Nginx reverse proxy from apache

In many ways, Apache can be viewed as a huge ship with tons of amenities — from a sauna to a pool, a buffet room and more. On the other hand, Nginx should be seen as a medium-sized steamer with the engine of a Ferrari.

The implication was clear, did we want a server that does 100 things decently despite only needing eight features? Or do we need a server that performs at least 10 times as fast with only 12 of those options.

Naturally, we chose the second option.

Results: (handling with 100 concurrent connections of same type)

• Apache server  —  1500 requests per second
• Nginx server  —  14000 requests per second

Implementing CDN on all static content across the server

Once we realized that the static content on our website — including the css, js and images — comes around to approximately 12 per cent of the entire source, the concept of a CDN (Content Delivery Network) began to make perfect sense.

In a world where the discovery/recommendation section of an app is meant to delight a user by making an awesome first impression, the importance of speed multiplies automatically.

The idea of a CDN is pretty simple in the sense that it aims to deliver content to the user from the server that is closest in terms of browsing location, hence saving unnecessary requests.

Also Read: How to start an app business in 7 steps: A Beginner’s Guide

Results: (handling with 100 concurrent connections of same type)
Static content was being delivered up to 2.16 times as fast

Multi-AZ deployment on Amazon RDS

The key focus of any engineer handling data is always the reliability and availability of data in the event of technical failure.

That is the precise problem that Multi-AZ deployment helps solve. After enabling the system, we were able to achieve protection against failures of disk, DB instances and even created a complete availability zone. The result was statistically the application became three times as resilient.

At present

We are working on adding a key and awesome update that will make peer to peer transactions universal from any bank to any bank, completely fast and insanely cool.

—

Rohit Taneja believes that design is a key essence on which the best products and connected businesses thrive. At the same time, getting the design in place is a very beautiful and delicate process that tends to depend heavily on the width of thoughts besides the very inherent element of creativity.

The original version of this article can be read on Medium.

Photo courtesy of Gratisography.

The post Tools of the trade: How Mypoolin made its app twenty times faster and tripled resiliency appeared first on e27.

from e27 http://ift.tt/1pg7ijv