Providing a large PaaS enterprise with a superior “last-mile” delivery and a customer-first experience

Optimizing Amazon SNS and Lambda impacting project performance & delivering a more engaging, higher-converting customer experience

>99% Performance reliability
2 Months to build product prototype
8 New features developed in each sprint

OnCorps provides a Decision Guidance platform that customizes rapidly to improve performance in asset management, sales, pricing, and forecasting. Serving premier global financial, consulting, and technology firms seeking an edge in decision analytics at lower costs. They leverage deep insights from data to assist enterprises to make better decisions using predictive analytics, machine learning and peer comparison.


  • Goal: To enable messaging between independent microservices.
  • Solution: Amazon SNS, Amazon SQS, AWS Lambda
  • Outcome: Seamless communication within a microservices architecture.

The Challenge

With the industry shifting to more AI-managed solutions. Reflecting this shift, OnCorps wanted to transition and required support to build a more solution focussed platform capable of heavy data lifting - from gathering, processing, analytics and visualization.

The new platform aimed to serve a diverse set of needs across business units and they specifically faced a challenge in delivering a platform with a well-functioning microservices architecture capable of ensuring a scalable, engaging, and higher-converting customer experience.

How the solution was deployed to meet the challenge

The solution was divided into two parts: First the core framework and second the microservices architecture.

Drupal was chosen as the core framework. At its core, while Drupal is extremely flexible, it is not equipped to carry out microservices functionality on its own. Therefore, multiple AWS solutions were engaged to offer scalable and cost-effective computation solution.

Solving with AWS

  • Amazon EC2: This offered an easily scalable and cost-effective computation solution. It gave the ability to run data analysis, compute workloads to aggregate data, as well as deliver predictive insight.

  • AWS Lambda: The frontend interface of the platform needed structured data to work with, preferably in JSON format. Lamba was used to transform the data coming in from various sources into a standard format.

  • Amazon S3: This was used to host the single page application built on AngularJS. S3 was also used as storage for all files and content assets for the platform.

  • AWS Cost Explorer: One of the Srijan teams primary objectives was to keep product development costs on track. AWS Cost Explorer was used to get a clear visualization of operation costs across all solutions, and optimize the budget as much as possible.

Other AWS Solutions include:

  • Amazon RDS as the database
  • Amazon Simple Queue Service (SQS) and Amazon Simple Notification Service (SNS) for customer notification mails and messages
  • AWS Organisations for security and compliance management

Third-party applications or solutions used



  • Scalable platform achieved with a well-functioning microservices architecture
  • >99% performance reliability across enterprise customers
  • Seamless platform integration with other services

Specific Architecture Diagrams, Deployment Guides and other materials depending on the type of solution

The move towards a microservices-based architecture led to the need for a messaging service which would allow sending messages between independent microservices using pub-sub architecture. This architecture had to be built for scale whilst allowing decoupling of each of the microservices. Here,

  • Different microservices were producers and consumers of the events.
  • To every event there was an associated topic in SNS.
  • To each topic there was an associated queue using SQS.
  • Lambda functions were used as event handlers thus keeping each of the microservices fully decoupled.

The final solution architecture looked like this.

solving microservices communication-1

The workflow of the solution was as follows:

  • Microservices act as producers of the event and each event could have multiple interested parties(consumers). All the interested parties are microservices as well.
  • Each event emitted by the producer has an associated topic in SNS, and for each topic in SNS there is an associated queue using SQS
  • For each SQS queue there is an associated lambda function which polls the queue and invokes your function synchronously with an event that contains queue messages. Lambda reads messages in batches and invokes your function once for each batch.
  • Lambda functions further invoke the microservice (consumers)
  • All the events are logged in Amazon CloudWatch, thus recording the event sequence of the flow.

Let’s start our conversation