12/11/2023 0 Comments Traffic spike meaningThe reads are checked in Redis first, and would fall back to the database only if the result isn’t found in Redis. The new writes to the database would be captured as table objects in Redis, against the table’s primary key identifier (to be later copied to the database). Our tech stack was redesigned to keep the Redis layer atop the database, and take the first hit as the traffic comes in. The high throughput in Redis allowed us to use it as a buffer against traffic spikes. The lookups were also fast, happening in constant - O(1) - time. It is ridiculously fast compared to databases by virtue of using RAM memory instead of a disk, allowing hundreds of thousands of reads/writes per second. While that might appear limiting for replacing a full-fledged database, there were multiple benefits we could unlock with Redis. In contrast to a relational database that stores entries as relationships between columns, Redis simply maps a key to a value. In more physical terms, we wanted a system with very high throughputs (handling a very high number of reads/ writes per second), and could be remodeled on the existing architecture with minimal changes to business logic and application code. It wasn’t about winning the last war, but being able to fight the next one with our growing scale requirements, it had to sustain exponential increases in demand. Moreover, we wanted a solution we could immediately implement - we could hardly afford to brood over a problem that threatened to bring down the entire payment processing system.Īnd yet, despite the urgency of the fix needed, we wanted a solution that was futuristic and not just a duct tape to tide over an immediate concern. That was given a skip because of a few domain constraints, additional overheads in managing the database and potential application changes that might be needed. We considered a number of solutions to this problem when we encountered it, including sharding the existing database (breaking up data into chunks and distributing it across physical database nodes), and abstracting it out of multiple physical ones. Much as we vertically scaled our relational database with more RAM and CPU, we soon hit upon limits: it became imperative to find a new solution. At its peak load, the volume of database accesses - especially the writes - become a bottleneck and stretch our database systems. These usually access the disk, which is a slower and costlier operation. While most of these are for reads (for finding and fetching data) and could be served through replica databases, there is still a high volume of writes (inserts and updates) that necessarily go to our main database.Īt Juspay, we have been using relational databases for recording real-time payment information (primarily a MySQL instance). The peak load thus translates to a very high number of database calls. Internally, one payment constitutes around 10 API calls and 100 database calls at Juspay. By a combination of an expanding clientele and an increasing propensity of users to transact online, our peak load in just the last 3-4 years have gone from 200 payments/ sec to soon approaching 3000 payments/ sec. The traffic could surge as much as 10x in a matter of minutes. Spikes in traffic are a common scene in the payments landscape.Time bound events like the IPL match starts, train ticket bookings, eCommerce offers etc, where a disproportionate volume of load weighs on a point in time (say, the last minute before a match start or an end of sale, or the first minute of tatkal booking). Hockey Stick Spike in Payments & its Effect on Databases In this article, we specifically look at our database systems and how we manage load at this scale. Or to put it more simply, our peak load is very, very different from the average. Likewise, our backend systems were meticulously designed to efficiently manage the highest levels of workload they might face.Īnd distribution of payments (number of payments/second) are fat tailed, meaning there is a very realistic probability for a value that is multiple standard deviations away from the mean to happen. When constructing a bridge, it must be engineered to withstand the maximum load it may ever encounter. Statistics such as averages and totals often fall short in providing a comprehensive picture. The Bridge that handles it allĮven though the number is significant, it fails to truly capture the scale of the problem at hand. Delivering in such situations is how Juspay has earned the trust of its partners. Think Diwali Sales, IPL, New year’s and so on… And, to handle this love customers pour upon their favourite online destinations, a robust Payments Infrastructure is as imperative as getting that iPhone on discount at Big Billion Day sale. Millions of customers hail rides, order food, buy groceries, listen to podcasts, or buy that dress they’ve been eyeing everyday.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |