Enhancing Loyalty rewards: How McDonald’s leverages AWS Lambda for microservices
A serverless, event-driven compute service enables us to push out new features in our Global Mobile App faster, at scale, and without infrastructure concerns.
by Kevin Nguyen, Software Engineer II
I’ve been a software engineer at McDonald’s for over 2.5 years. One of the things I like most about working in the Global Technology function is the opportunity to use state-of-the-art technologies, work in new ways, and define best practices. I currently sit on the team that works on the back-end account capabilities for our Global Mobile App (GMA), such as user registration and authentication microservices.
Microservices are a type of architecture style that structures applications as small, maintainable collections of code, enabling engineers to be more agile and scale out their services to meet most business needs — but what if a 24/7-running microservice isn’t required?
This is where we turn to a serverless, event-driven compute service. At McDonald’s, we’ve adopted AWS Lambda to allow developers to focus on coding and pushing out new features faster, at scale, and without infrastructure concerns.
In choosing a solution, we considered product limitations, such as:
- Time limits — hard stops are not ideal for McDonald’s long running processes.
- Cold starts — delays in code execution after extended periods of time, which is not ideal for McDonald’s in time-sensitive situations.
- State management — if using a stateless solution (like AWS Lambda), developers would need to rely on external storage, such as a database for state persistence.
Ultimately, we decided to use AWS Lambda as a key component in our microservices.
We leverage AWS Lambda to publish account activities onto our Loyalty Reward System in our GMA.
Here is a simple scenario where a user registers their account in the GMA while simultaneously getting processed into our Loyalty Reward System.
User data publishes messages into a traditional AWS Simple Notification Service and Simple Queue Service (SQS) combo. The AWS Lambda polls from SQS and processes that message.
In this case, it makes sense for the AWS Lambda to directly process the request to the Loyalty Reward System because:
- The AWS Lambda code only involves working with the Loyalty Reward System. It does not make sense to put unrelated code onto the main microservices.
- While the microservice invoking the Representational State Transfer (REST) call to the Loyalty Reward System can take some time, with AWS Lambda, the call to our Loyalty Reward System is processed asynchronously, so the customer has a smooth experience throughout the app.
How we optimized our microservices platform
By nature, AWS Lambda assists with asynchronous tasks. Because of this, we’ve seen customers on the Loyalty Reward System experience out-of-order transactions, which required manual intervention to remediate errors.
There was room for error with the prior system setup, especially since each loyalty event is pipelined to separate SQS and AWS Lambdas. We did not have the ability to coordinate these transactions per user, nor does AWS’s standard SQS guarantee that the message is delivered in order.
We use SNS/SQS First-In-First-Out (FIFO) queues, which helps ensure the ordering of the transaction and exactly-once processing. However, since SQS FIFO has a lower throughput and higher cost than the standard SQS, our engineering team refactored code and infrastructure. We now experience fewer out-of-order transaction errors, freeing up our team to focus on higher-priority tasks.
An engineer’s perspective
Before joining McDonald’s, I developed software and worked with infrastructure engineers in deploying code changes onto traditional on-premises data centers across the country.
The opportunity to witness how McDonald’s deploys software changes so quickly has given me a huge appreciation for the cloud and helped me unlock new possibilities in designing systems!
