Skip to main content

Quickwork Technology Pvt. Ltd.


Quickwork provides an all-in-one platform with the tools and services you need to build powerful & scalable integrations, serverless APIs, conversational experiences, and a lot more! This supports all types of events used in automated workflows, such as real-time, polling, scheduled, and manual. This unique capability enables building a wide range of workflows across industry verticals.


Client wanted to provide the solution which helps to make Automation easy, affordable, accessible and compliant. There aim to trigger the workflow in real-time as soon as the event occurs in the source application systems.This event type is suitable for conversational, IoT, financial, and other use cases that require instantaneous response Since there is a case where millions of such events can occur it needed the infrastructure to support this. Also these events won’t be there in the system for more than 15 to 20 seconds. That means they only need the processing power for < 30 seconds when an event occur. And whenever event occur there should not be more than 1 or 2 seconds of delay accepted to process the event.



The CI (continuous integration) process is managed using Jenkins. An image is pulled from docker repository, customized with application code and then pushed to Amazon Elastic Container Registry (Amazon ECR). In the CD (continuous delivery) process, the image is pulled from Amazon ECR and applied in the respective Kubernetes namespace.


The TECHPARTNER team worked with the Quickwork management team and tech leads to understand the project needs. Together we chalked down the plan and finalized the architecture. Our focus was to leverage AWS services and utilize the open source tools to achieve the required output.

To process millions of events which will be there in the system for < than 30 seconds there is no other service better than EKS. We use AWS EKS to support the scale and faster rollout. The architecture consisted of setting up auto-scaling nodegroups using a mix of on demand and spot instances for better performance, scalability and cost optimization.

We Implemented the KEDA which is a kubernetes based event Driven Autoscaler. With KEDA you can drive the scaling of any container in kubernetes based on the number of events needing to be processed.


Scalable Architecture : With the scalable architecture Quickwork was able to serve the user with improved response time which in turns helped to acquire more users
Performance : As the application and deployment is modular, the whole CI/CD process became easy and efficient
Automation : Automation reduced the manual deployment time by 90% giving free hand to developer to concentrate on Innovation

With Scalable EKS architecture along with KEDA, the client was easily able to launch more than 2 Million of pods on the EKS cluster to execute the customer workflows in a day without any hiccups.


  • AWS WAF: Since this is a consumer facing application, WAF is suggested for better security.
  • AWS CloudFront: The frontend of the application is served via CloudFront for quicker response to customers and take advantage of CloudFront edge locations.
  • Amazon Elastic Kubernetes Service (EKS): The EKS is used to host and deploy the application stack.
  • AWS Application Load Balancer (ALB): The application is hosted on ECS. The ALB is used to load balance and expose the application to the internet. ACM is used to generate SSL certificates and applications are made to serve only SSL encrypted
    payload to end customers.
  • AWS EC2 instances: A mix of on-demand and spot instances is used for hosting all the applications on ECS nodes. Node autoscaler and HPA (horizontal pod autoscaler) is used to scale in and scale out applications depending on end traffic load.
  • AWS ElastiCache: ElastiCache Redis is used to store the session and transient data.
  • AWS Lambda: Multiple Lambda jobs have been written in Node.js ver 14.x for application functionality
  • AWS Managed Streaming for Apache Kafka (MSK): MSK is used to process streaming data and jobs.
  • AWS Cloudwatch: AWS Cloudwatch is used for monitoring and alerting. Resource usage of the infrastructure is monitored using Cloudwatch dashboards. Whenever any critical threshold is breached (e.g. too many 5xx on ALB), an alert is sent out to the Operations and Engineering team for investigation. Billing alerts have also been set.
  • AWS Route53: Route53 is being used for DNS. DNS zones are set for internal as well as public facing records.
  • AWS S3: S3 is used for storing frontend application code and static assets (which are served by CloudFront eventually). S3 is also used to store backup data.
  • AWS Lifecycle Manager: It is used to take instance’s image backup.
  • AWS RDS: MySQL and Postgresql are used to store the transactional backed data.
  • AWS Key Management Service (KMS): KMS is used to encrypt all data storage volumes using custom keys.