The Technology Behind KFC’s Finger Lickin’ Good Success

https://aws.amazon.com/blogs/architecture/the-technology-behind-kfcs-finger-lickin-good-success/

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.

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.

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

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

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

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

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.Original Post>

Figure 7. Store and time pattern

Conclusion

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.