AWS Partner Network (APN) Blog

How Cognizant OrderServ Saves 90% on Infrastructure Costs with AWS Serverless Architecture

By Sukrity Chakraborty, Sr. Architect at Cognizant Technology Solutions
By Sundararajan Narasiman, Partner Solutions Architect at AWS
By Priyanka Phadikar, Architect at Cognizant Technology Solutions

Cognizant-APN Badge-5
Connect with Cognizant-2

Digital food ordering is one of the most rapidly growing global industries today. Gone are the days when you had to call up a restaurant, wait to get connected, ask an operator for the daily specials, and then place your order.

Even for dining out, you had to wait in a queue to place your order and then convey to the kitchen staff that you don’t want mushrooms on your pizza.

Nowadays, customers expect the flexibility to order food through multiple channels. Whether in store, at home, or on the go, customers want to order their favorite meal and get it delivered quickly. Moreover, they expect restaurants to remember their favorite items and suggest new and relevant offers based on their order history and preferences.

Based on these customer needs, Cognizant’s OrderServ is an omnichannel digital ordering platform designed for the restaurant and food services industry.

In this post, we will describe how the Cognizant OrderServ platform (for a Kiosk channel) leveraged the AWS Serverless architecture and realized Amazon Web Services (AWS) infrastructure cost savings of 90 percent along with scalability improvements.

Cognizant is an AWS Premier Consulting Partner with five AWS Competencies. Cognizant is also a member of the AWS Managed Service Provider (MSP) and AWS Well-Architected Partner Programs.

OrderServ Facts

OrderServ is a software-as-a-service (SaaS) platform hosted on AWS. With OrderServ, restaurants and food service businesses can drive sales through digital channels such as responsive websites, mobile apps, kiosks, and conversational channels like Alexa Skills and chatbots.

It offers a seamless omnichannel food ordering experience to end customers, and helps restaurants increase revenue through intelligent upsell.

OrderServ is currently deployed in 10 different AWS regions, serving global restaurant chains across five continents. OrderServ processes 1.2 – 1.5 million transactions per month, which doubles during the holiday season.

OrderServ Functional Architecture

The OrderServ platform has three major components: ordering, integration, and admin modules.


Figure 1 – OrderServ functional architecture.

The Ordering module implements functionalities such as Store Search, Menu Search, Item Selection, Basket Management, Checkout, Payment, and Customer Profile Management. It caters to the functionalities used by the end customer.

The Integration module facilitates interaction of the Ordering module with external systems such as Point of Sale (POS), payment gateways, loyalty systems, delivery providers, CRM systems, web analytics providers, geo-map providers, and social medial platforms.

Restaurant managers, marketing, and operations teams use the Admin module for back-of-house operations such as inventory management, menu management, onboarding of new restaurants, real-time dashboards, and reports.

OrderServ Technology Stack

The OrderServ platform has three primary channels for food ordering:

  • Responsive website – This is implemented using Microsoft ASP.NET MVC 5 framework, and interacts with Microsoft SQL Server database.
  • Kiosk application – This app invokes OrderServ Core APIs to complete the required transactions for customers. OrderServ Core APIs are implemented using Microsoft ASP.NET Web API framework.
  • Cross-platform mobile application – This is developed using the Xamarin framework.

OrderServ First-Generation Deployment Architecture for Kiosk

The first generation of OrderServ deployment focused more on embracing the AWS platform faster, reducing cycle time, and demonstrating quicker business wins.

The following figure represents OrderServ’s first-generation deployment architecture.


Figure 2 – OrderServ’s first-generation deployment architecture.

Here are some of OrderServ’s first-generation highlights:

Design for Failure

OrderServ is designed for failure. It leverages multi-Availability Zone deployment and Elastic Load Balancing with Application Load Balancers for web tiers.

Though it does not leverage Amazon Relational Database Service (Amazon RDS), it uses a stand-by database instance in a different AWS Availability Zone.

Network Segmentation

OrderServ platform components are deployed inside an Amazon Virtual Private Cloud (Amazon VPC) with dedicated subnets for the web and data tiers, configured across Availability Zones. The web server hosts Responsive Web Application and OrderServ Core RESTful API.

Persistence Options

The relational database (SQL Server) is leveraged for storing both master data and transactional data. The store-specific configuration data is persisted in Amazon Elasticache for Redis.

Security in Every Layer

Security is implemented in every layer of OrderServ, which implements data encryption at rest and in transit. It also follows the principle of least privilege with AWS Identity and Access Management (IAM) users, roles, groups, and policies. OrderServ also leverages AWS Security Groups and Network Access Control Lists (ACLs) to harden Amazon VPCs.

Elasticity for Web Tier

OrderServ web tier does not make assumptions for compute capacity, health, and availability of components. It adopts elasticity in the architecture by leveraging AWS services such as AWS Auto Scaling, Elastic Load Balancing, and custom Amazon CloudWatch metrics.

This architecture did not have gaps until OrderServ encountered order spikes in the holiday season of 2018.

Order Spikes and Scalability Challenges for Kiosk Channel

During the holiday season of 2018-19, the OrderServ platform witnessed a surge in the amount of orders through Kiosk. OrderServ Core APIs experienced a massive spike in load, which cascaded to the database as well.

Since APIs were hosted in a fleet of Amazon Elastic Compute Cloud (Amazon EC2) instances, auto scaling handled load spikes in web tier. For SQL Server database, Cognizant evaluated the option of database sharding. It was not feasible due to constraints posed by the components of the current architecture.

Instead, Cognizant scaled up the database instances to handle spike in load. The scale-out and scale-up of instances also increased the AWS infrastructure costs for that month.

The OrderServ team identified the following as bottlenecks for scalability and cost optimization:

  • Strong coupling between Core APIs and SQL Server lead to an increase in database usage.
  • Strong coupling between Kiosk application and OrderServ Core APIs hosted in web tier lead to an increase in number of API calls.
  • Lack of detailed monitoring, logging, and tracking of APIs.
  • Kiosk application had to frequently poll the Core APIs even for master data changes, leading to an increase in compute usage in web tier.
  • Since Core API is a monolith, there’s no way to scale it independently in a granular fashion.
  • No visual way to represent APIs, its interactions, and behaviors, which posed troubleshooting challenges for support teams.
  • Scalability bottlenecks in Redis cache during peak load.

Tenets for OrderServ Platform Modernization for Kiosk

The path forward to improve scalability, agility, and performance of OrderServ was to embrace a microservices-based architecture. With this goal, the OrderServ team identified the following tenets for platform modernization:

  1. Break down the large monolith Core API into multiple granular and autonomous microservices so they can be independently scaled, versioned, deployed, upgraded, and managed.
  2. Reduce dependency of Core API on SQL Server.
  3. Reduce dependency on SQL Server database. Embrace AWS Serverless database for both master and transactional data.
  4. Reduce dependency of Kiosk application with Core APIs. Implement push-based communication from Cloud APIs to Kiosk.
  5. Implement detailed monitoring, tracing, and logging of microservice components.
  6. Visually represent microservices and their interaction.
  7. Leverage a gateway to publish, maintain, monitor, and secure microservices at scale.
  8. Use AWS Serverless compute services to offer a baseline provisioned capacity and support auto scaling.
  9. Embrace event-driven architecture style, de-couple microservices using messaging queues, and adopt a fan-out architecture pattern.

In the next section, we’ll describe details of OrderServ’s architecture modernization.

AWS Serverless Architecture for OrderServ Kiosk

The Core APIs are broken down into to multiple granular and autonomous microservices, implemented in AWS Lambda.

These microservices are de-coupled using Amazon Simple Notification Service (SNS) topics and subscriptions, exposed using Amazon API Gateway. Amazon DynamoDB acts as the persistence layer.


Figure 3 – OrderServ’s serverless deployment architecture.

Here are some of OrderServ’s serverless architecture highlights:

Serverless Compute

The monolith OrderServ Core API (ASP.NET Web API) is re-factored as multiple, granular, independent, and autonomous AWS Lambda functions using Node.js. These Lambda functions are exposed as RESTful APIs using Amazon API Gateway.

Some of those APIs are exposed through a WebSockets channel as well. This enables push-based updates of master data to the Kiosk user interface. The Lambda functions are configured with provisioned concurrency.


Amazon API Gateway is leveraged to deploy, publish, maintain, monitor, and secure microservices at scale.


Each of the Lambda functions are short-lived and get invoked based on an event triggered from business transactions. The functions are stateless as well.

Fan Out

Often times, an event requires multiple activities to be completed independently. To accomplish this, an event arising from a source is published into multiple SNS topics. The subscribers of these topics are independent Lambda functions; they get invoked and executed as a part of subscription fulfillment.


A custom Lambda authorizer is in place to handle authentication of APIs.

Loose Coupling

No two Lambda functions are dependent on each other. These are de-coupled using SNS.

No SQL Data Store

Both the master and configuration data are moved from SQL Server to Amazon DynamoDB, which is configured with provisioned throughput and auto scaling is also enabled.

The hot data resides in Amazon DynamoDB for 30 days. After that, it’s moved to a central data lake hosted on Amazon Simple Storage Service (Amazon S3).

Observability and Tracing

Amazon X-Ray is used inside Lambda to support detailed tracing for Lambda functions. The ServiceMap is extensively leveraged for observability for microservices.


Amazon CloudWatch is used to continuously log and monitor all the activities of Lambda functions and other components.

Business Benefits

The serverless architecture of OrderServ Kiosk was implemented in Q4 2019 for a new customer of a leading quick-service restaurant chain. OrderServ Kiosk serverless architecture helped them handle load spikes during holiday season of 2019-20.

These were the benefits realized by this new architecture:

  • Reduction in AWS infrastructure costs by 90 percent even with order spikes.
  • Improved scalability – OrderServ was able to handle surge in orders with ease.
  • Improved availability – No downtime or latency issues.
  • Faster time-to-market changes.
  • Better observability and monitoring of services.
  • Reduction in cycle time for development and testing.
  • Reduction in cycle time for support (L1, L2, and L3 teams).
  • Improved customer satisfaction.

Next Steps for OrderServ Platform

As an endeavor towards continuous improvement, Cognizant’s OrderServ team identifies the following Kaizen items for the future:

  • Embrace AWS Serverless architecture for all of the other channels of OrderServ. Containerize the Responsive Web Application by using Amazon Elastic Container Service (Amazon ECS) on AWS Fargate.
  • Reduce Windows licensing cost by modernizing Responsive Web Application to ASP.NET MVC Core for Linux support.
  • Eliminate SQL Server dependency for commerce server by migrating to Amazon Aurora database.
  • Implement a fully automated CI/CD pipeline using AWS Code Pipeline.
  • Adopt artificial intelligence (AI) and machine learning (ML) capabilities. Implement personalized food recommendation by adopting Amazon Personalize.


With AWS Serverless, Cognizant OrderServ was able to migrate to a microservices architecture and scale to meet seasonal demands at 90 percent the cost of a traditional hosted architecture.

OrderServ utilized AWS services such as AWS Lambda to fetch master data and process orders, Amazon DynamoDB to efficiently store complex menu hierarchy, Amazon API Gateway to create REST and WebSocket APIs, and Amazon SNS to integrate microservices and fan out events for processing.

“OrderServ has evolved from a web ordering platform to an end-to-end omnichannel system,” says Wael Dowidar, Digital Strategy Director at Kentucky Fried Chicken. “It is equipped with administrative features to run the day-to-day business, store, menu, order management, report. It’s easy to integrate with other platforms and payment gateways.”

To learn more about OrderServ , please visit the Cognizant OrderServ website.

Cognizant – AWS Partner Spotlight

Cognizant is an APN Premier Consulting Partner that transforms customers’ business, operating, and technology models for the digital era by helping organizations envision, build, and run more innovative and efficient businesses.

Contact Cognizant | Partner Overview

*Already worked with Cognizant? Rate this Partner

*To review an AWS Partner, you must be an customer that has worked with them directly on a project.