Welcome to 'This is My Architecture'.
Today, I'm joined by Robbie from Taco Bell.
Welcome, Robbie. Thanks for having me.
So, for those, everybody knows Taco Bell,
but for those few folks who don't, tell us what Taco Bell does.
Sure, so Taco Bell is the nation's leading Mexican Inspired QSR brand,
and we serve over 42 million customers per week.
Forty two million is a big number.
A lot of tacos, yeah. Yeah.
So, we're gonna talk about your architecture here, today;
or at least a piece of it. What are we looking at here
on the board?
Yeah, today I'm gonna share what we call our menu middleware
and data integration platform. This is a core system at Taco Bell,
and it allows us to generate menus for 7,000 restaurants
on multiple delivery channels.
Okay. You know,
being able to get a delivery has been pretty critical over the last year.
Let's dive into it and show us how it works.
Awesome, so yeah.
We'll start with the different sources of data.
Here, you see there's an Aurora MySQL database.
So that's like, the core centerpiece of this,
where the data's gonna reside.
But there's different systems of entry. So, we have what we can an RCC.
Restaurant Control Center app that we built.
Really exciting. We're using Amplify to deploy React app.
And this is, the restaurant hours are maintained in this database.
Cool, so the store owner can update their hours.
So each one of those 7,000 stores can have their own control
over what their hours are. Yeah, and they are
mostly different, so they could be.
So, this has a DynamoDB backend. We also use DynamoDB Streams
which is really cool here. So this is kind of, that real-time feed
into this system. So, that will eventually call a Lambda,
and we'll load some restaurant hours tables in here.
Right, because I need to know when the store is open,
so I can place my order.
If you try to place an order and it's actually closed,
you're not going to be very happy. So it's up to me to make sure
that gets in there very quickly. Got it.
So, the second system I want to show is our product master,
so that's really critical. Our data management team goes
into a separate application and sets up the new products.
So, we come out with a crazy new taco, we come out with some burrito
that's going to end up here. Tons of other stuff goes into it.
You know, the makeup, that product.
And then what's gonna do is, they're gonna do a CSV export
to an S3 bucket, and it's gonna trigger into a system
that we created called Diablo. Diablo, okay.
I've heard of that before. So, at Taco Bell we like
to name our internal products off of our food,
so Diablo is our hot sauce.
And it stands for Data Integration and Automation
Batch Lambda Orchestration. Wow.
Diablo is a lot easier. Diablo's easier,
so we just call it Diablo. It's a really cool thing,
so it's built on stuff functions for the orchestration
and it calls Lambda, but the Lambda's are kind of unique.
So, we wrote these Python step types,
and they're very generic reusable steps.
So, you find out you do something a lot, you're like this should be a step type.
Write it, put it into Diablo, anyone else can use it.
Here, it's taking data from a database and putting it
into another database. We abstract everything out,
we make it just super easy to do.
So, and that's allowing you to build a horizontal service
inside of your company?
You're kind of building your own internal web service,
is that accurate? It is like a product standing
on the shoulders of AWS.
We love it though because we don't have to worry about the scheduling,
the infrastructure, there's a lot that goes
into Step Functions, obviously. That's something we don't have
to worry about. We just focus on the business value
which is our step types. And we just keep adding steps,
and we just keep making our lives easier.
I love it. Yeah, so this loads data in here.
It's a batch process, so we use EventBridge you know,
cron schedules to make sure that gets in there at a certain time.
And then the last source of data is pricing and tax information;
very critical as you know. Yeah.
I don't want to be paying too much.
And it's interesting because there's over 100 million combinations
of pricing data in this database.
It's not just 7,000 restaurants and the taco,
there's modifiers, there's swap rules, there's all these complicated things
that we have to maintain in this database.
So again, we have something handy called Diablo.
Just create a new workflow. Very quickly we were able
to get this data into here as well so that also gets loaded.
So now we have, you know, restaurant hours,
we have the product information, we have the pricing and tax information;
we're ready to go. That's everything we need
to create a menu? Pretty much, yeah.
Okay, so what happens next?
Alright, so as I mentioned there's 7,000 restaurants,
there's multiple delivery aggregators and there's other channels.
They're all waiting for that new product to come out.
What we call an experience launch.
Those are the days where we're gonna have to generate basically 40,000 menus.
And we have a very small down time, you know, when the stores close.
We do them based on time zone, but they need to get up
by a certain time. So, luckily we have the scalability
of AWS behind us. So what we do is we just queue those up,
we have an SQS queue trigger something called
the menu exporter Lambda.
Basically processes, takes the data from this database,
spins it up how it needs to be, creates these complex JSON menus.
They all have these big object menus.
And the menus are very big, so you're looking at 100 gigs
of just raw menu data that's passing through the wire
to these delivery aggregators. Wow.
That's a lot of tacos. A lot of tacos, it scales very quickly,
and it's able to process that.
So, what they'll do is they'll generate the menus,
send it to the delivery aggregators;
they'll process it when they're ready right away or maybe a few seconds later.
And then they'll send webhooks back,
basically telling us if it succeeded or failed.
And we'll pipe that back in, and we'll mark it in the audit table
that it was processed successfully.
So, that means that menu is now live on the restaurant.
So it's in production and I can pull out my phone and place an order.
You can place whatever you want, it's ready to go.
Neat. So we're looking at Aurora
here as a centerpiece of this architecture,
tell me a little bit about why you're using Aurora
and what benefits you're getting from that.
Mm-hmm. So Aurora was perfect for us
because a lot of us had a relational background
so it was comfortable for us, but they also handled
the stuff we didn't care about; like the database administrative tasks,
the scaling, read well because they're just available.
They can autoscale for you. Ao on days when we have to do that
that's very valuable. There's gonna be hotspots
where things are going fast, so Aurora just scales perfectly for us.
And it's able to handle the massive number of Lambdas
that we're queuing up. So this is a really interesting
architecture, Robbie. And I love having Aurora
as that centerpiece . It's all serverless.
Any other benefits that you're getting from this architecture?
So we talked about the scaling, we talked about how just Step Functions
are so flexible and everything, it's also incredibly cost effective
to run this entire system.
Not having to worry about the infrastructure,
we have a very small scrappy team and we're able to do a lot
with that team based on this cool platform.
Well, thank you for sharing your architecture with us today.
It's really interesting.
And thank you for watching, 'This is My Architecture'.