AWS Architecture Blog

The Technology Behind KFC’s Finger Lickin’ Good Success

This post was written by Jaime Hall of KFC

At Kentucky Fried Chicken (KFC), our platform has constantly evolved over the past four years. Since the shift to bring all development in house, we’ve been making great progress. During this time, KFC has grown dramatically within the digital space. Underpinning it all, we aim to make it as easy as possible to order our great chicken.

Some innovations that have helped us get closer to this goal include: fully integrated aggregator delivery, collect service via the front counter or drive-thru, table service, improved loyalty system, in-store kiosk integrations, direct point of sale (POS) integration, and a centralized menu service. There is much more to come, as well! KFC’s digital technology stack has grown to process nearly half of the transactions processed through our restaurants.

To build these applications and services, we partnered with AWS to implement a serverless infrastructure. Our stack was originally a fully Terraform implementation, but we chose to adopt a hybrid model of Terraform and the serverless framework. Our language of choice was Node.JS. This allowed us to create a more microservice-based topology. This setup puts the full system of development within the service teams. It also allows us to move towards a continuous delivery lifecycle while keeping it fully automated as part of the infrastructure for code.

We created a series of design patterns to follow within each of our services. This allows for a fully event-driven logic and highly scalable system while keeping standardized services, which is key to creating a successful design. Scalability can be fairly predictable due to peak ordering food times, but we also need to be able to handle unexpected orders as well. For example, the recent shift from on-premises to web ordering has put our design to test.

The following sections show some of the design patterns we use to solve some of our more unique requirements like accepting orders to be processed asynchronously and processing orders on a first-come-first-serve basis when dealing with 950+ restaurants.

Accept, queue, and process with Amazon SQS and AWS Step Functions

This design pattern is used heavily as part of any webhook process. It is performed asynchronously with queueing. In this design pattern, authorization can be customized in the initial AWS Lambda function depending on the payload’s origin. This pattern allows us to quickly accept and process orders. It also gives control back to the webpage and updates the page as the order status is updated.

The figure shows the accept, queue, and process design pattern, which consists of five icons in a straight, horizontal line. The first icon is a computer screen with the label “client.” It is connected to the next icon for Amazon API Gateway by a double-sided arrow, indicating the client and API Gateway continuously talk to each other. The third icon for AWS Lambda is also connected by a double-sided arrow, indicating it continuously talks to the API Gateway. The AWS Lambda icon, the fourth icon in the row, has a one-way arrow point to the next icon for Amazon SQS. The Amazon SQS icon, the fourth icon in the row, has a one-way arrow that points to the final icon for AWS Step Functions.

Figure 1. Accept, queue, and process pattern

Service communication with Amazon SNS and Amazon SQS

This design pattern allows communication or processing between services while decoupling them from one another, minimizing each services’ reliance on the other. For example, this could look like the email service notifying a customer that their order has been processed successfully via the order service. Or it can include the payment service notifying the order service that an order has been paid for successfully.

This figure shows the service communication design pattern, which consists of 5 icons. On the far left, AWS Lambda is shown with an arrow pointing towards AWS Step Functions. AWS Step Functions points towards Amazon SNS. Amazon SNS has two arrows that point at two boxes to the right that are stacked on top of one another. Both boxes contain an icon for Amazon SQS and are labeled "microservice."

Figure 2. Service Communication Pattern

Guaranteed single message delivery with conditional concurrency with Amazon SQS

This design pattern is used when guaranteed delivery is required. It also needs to throttle the flow of the system with specific parallelism through grouping. One of our use cases for this is order injection into our restaurants where we want to send orders in a strict first-in-first-out basis and one order at a time while still being able to inject into multiple restaurants at the same time.

Figure 3. Guaranteed Delivery Pattern

Figure 3. Guaranteed delivery pattern

Reporting stream with Amazon S3 and Amazon Athena

This design pattern is used for long-term storage of transient data for post analysis or querying for reporting/analytics. This allows us to perform detailed historical analysis of order processing, routing, and SLAs to identify any root causes and process improvements.

Figure 4. Reporting Stream Pattern

Figure 4. Reporting stream pattern

Tidy and archive with Amazon DynamoDB and Amazon S3

Using Amazon DynamoDB to maintain restaurant transient data, we use its Time to Live (TTL) mechanism to automatically clean and persist the data. Amazon Simple Storage Service (Amazon S3) offers a cheap, long-term storage solution ready for future use for things like predictive analytics to customer personalization.

Figure 5. Tidy and Archive Pattern

Figure 5. Tidy and archive pattern

Store and process Amazon SQS and Amazon S3

This design pattern offers long-term storage with replay ability while still maintaining a fully event-driven process. This pattern is used extensively when processing large payloads like restaurant transactions where a high throughput/concurrency requires throttling, which in our case is handled through Amazon Simple Queue Service (Amazon SQS).

Figure 6. Store and process pattern

Figure 6. Store and process pattern

Store and time process with Amazon DynamoDB and Amazon SQS

This design pattern allows for a holding gate with timed processing on a per-payload basis. It uses Amazon SQS to throttle downstream processing for when the gate/time is up. It also allows for a single delivery and easy replay.

Figure 7. Store and time pattern


AWS serverless infrastructure has allowed KFC to create a highly scalable, quick-to-market digital platform. It gives us the ability to develop applications and services quickly and also gives us the flexibility and agility to adapt quickly within the quick-service restaurant market. Because of this, we have seen accelerated growth and scale, which has ultimately provided greater flexibility to our customers to buy finger lickin’ good chicken wherever and whenever.

Jaime Hall

Jaime Hall

Jaime Hall is Head of Architecture at KFC, Leading on both the restaurant and digital architecture he has over 20 years experience in digital technology and is passionate about Serverless technology and event-driven processes while leveraging the power of AWS system.