Simplify your cloud architecture

Shipping A Planet-Scale Cloud Platform in Two Months at Mastercard

We needed to get a service to 100,000 requests per second to serve enterprise customers at scale. The service and the database ran on dedicated instances, with scaling requiring a heavy involvement from the operational team. Furthermore, the service was deeply coupled to the rest of the monolith architecture, and it was impossible to deploy it without deploying the entire product. This existing architecture had trouble scaling beyond 1000 requests per second, and we wanted it at 100x.

We had eight weeks to show the product and prove that it could scale 100 times. The demo date was scheduled in advance and had senior VP and C-level stakeholders. In addition, we had to write the service in Java to align with the company's technology stack. At the same time, the team was used to working with the PHP codebase and had a fundamental knowledge of modern cloud architectures. The expectation was that we run a load test at 100,000 requests per second against production API endpoints while returning the desired result. We had two months to do the impossible.

The team experienced a firehose of knowledge acquisition for the first two sprints. No one knew what a fat Jar was until we had to put a Java artifact into a Lambda function. The team was learning for the first two sprints and wrote very little code. However, in the last two sprints, the code velocity picked up. We dove into the cloud world and worked with solutions architects to review the best practice architectures and get code samples. We deployed infrastructure and ran regression tests on every build. We hit the deadline, and we were able to run a load test at 100,000 requests per second and return the desired result to the delight of the stakeholders.

So how did we do it? We chose simple architectures while leveraging the power of the cloud to make it happen, and we did not try to reinvent the wheel. We stripped the service down to its core functionality, where we could put the entire business logic in a serverless function. We used NoSQL as the data store and leveraged existing gateway functionality for authorization. In addition, we built the new product in a highly modular way, containing libraries for event logging, authentication, etc., that enabled us to deploy and iterate on decoupled artifacts fast.

The architecture for your product should be simple and easy to understand. When it comes to architecting system components in the cloud, less is more, as each system boundary adds potential points of failure and increases maintenance. The goal is to minimize operational complexity and allow the rapid iteration of essential product features.