Engineering Guide to Food Trucks

Nov 06, 2019

Many engineering problems have real-life counterparts. If we think enough, we can draw a real-world analogy for most of the engineering problems. At Fyle, we recently built Jobs Infrastructure - a background job processing framework, which resembles how food trucks operate.

We all have been to food trucks, right? From the outside it looks very simple. People place the order, get the food and yum yum! But what does it take to successfully run a food truck? Let's figure out what are the different kinds of challenges we may face if we were to set up a food truck of our own and what are the possible solutions to these problems.

Setting up counter and kitchen

Attempt #1: The very first thing we do is, we set up a counter and a kitchen. At this point we have no idea about the number and size of the orders that we would be receiving, and we need to start somewhere, so we just start with a single person. This person is responsible for both: the counter work and the kitchen.

Customer comes, places order to this person, this person asks him to wait for a while, and then goes on to prepare the order. Once done with the preparation, she comes back with the food and provides it to the customer. Easy peasy, right? This works. We have a minimum-overhead lean model, which works very well for small orders. But there's a problem:

People may come with BIG size orders. These orders need a huge amount of time to get processed. This person is capable of doing it, it's just gonna take a lot of time.

This doesn’t sound very good. It's not nice to keep customers unattended for so long. Not a good “user experience”. We need to think of something.

Hiring a cook

Attempt #2: What we do next is, we hire a cook. And we make the existing person as the counter person. They two have different roles. Counter person acts as the front desk of the food truck. Her responsibility is to handle orders and pass the order requests to the cook. Cook's responsibility is to take care of kitchen work. We separate their concerns[1].

How does the counter person pass order requests to cook? She uses stickies:

The advantage of this new arrangement is that, as soon as the counter person is done posting the sticky, her job is done. Regardless of the size of the order, the counter person becomes instantly available to the customer. Cook picks up the sticky and starts preparing the order "asynchronously". We decoupled the two fundamentally different kinds of work: managing orders and preparing them; by hiring a cook and installing a sticky mechanism between him and the counter person[2].

By the way, what does the counter person write on the sticky? Dish name? Recipe? Quantity? Preferences? Does the counter person really need to write the recipe on the sticky?

Let’s say the order is for Rawa Masala Dosa. The counter person need not describe how to cook an RMD on the sticky. Knowing how to cook is not her job anymore. Our cook is intelligent. He already knows how to cook RMD. All the counter person needs to tell is, what dish has to be made, quantity and preferences, if any: {name: Rava Masala Dosa | quantity:2 | spice_level: high etc.}

Also, cook needs to update the counter person about the happening of the orders. When he finishes the preparation he hands over the dish to the counter person. In case any "exception" occurs, like "eggs not found", he updates the counter person about order not being processed along with the reason.

This looks nice, but there are still a couple of issues:

First, it's very difficult for the counter person to keep track of all this information for each order that she receives.
Second, how do we figure out how our food truck business is doing? How do we answer questions like: How much did we make? How many orders did we process so far? What is the average cooking time? Average waiting time? Frequent customers? Power customers?

Maintaining a register

Attempt #3: We provide the counter person with a register to maintain. Because the stickies are volatile in nature. Order appears there, cook takes that order, and then the order disappears. To audit, we need to make note of the information at a more “permanent” place - in a register.

With that in place, this is how things work: Counter person receives an order from the customer. The first thing she does is, make a note of this order in the register. She can record all sort of interesting info about the order, for example:

when was the order placed
what item was requested
any preferences
who placed the order
when did she pass the order to the kitchen

After taking the note of the order, counter person continues with the same process of passing the order details to the cook via the stickies.

Remember: the cook cannot himself write to the counter person's register. Why? Because cook doesn't have "access" to the register. The best he can do is, let the counter person know of the updates and then the counter person can in-turn maintain the data in her register.

Putting the counter person, the cook with recipes, the stickies, and the register altogether, this is how it looks:

Nice! Now that we are maintaining all sort of details in the register, we can derive answers to our queries from it. One question though:

How does the customer know about the happenings of his order?

Being proactive

There are two ways for a customer to know about the updates on his order:

I’ll follow up: Customer comes up to counter person at frequent intervals and checks up on the status of the order. And remember, the counter person now smartly maintains the register? So, she just needs the order number from the customer and is capable of sharing all the details about the order status.
Keep me POSTed: There is another way. While placing the order, along with telling the order-item and preferences, customer also provides his contact details. This way the counter person can pro-actively let the customer know about the updates of the order.

Attempt #4: We take the contact details as input from the customer. And then we proactively update the customer whenever something interesting happens with the order, like COOKING_STARTED, COOKING_COMPLETED, COOKING_FAILED etc. etc.

Why can’t cook directly pass on the status/dish to the customer? Well, while this seems obvious, this is not possible. Reason being, cook simply doesn't know anything about customer. He need not know. And if we notice, counter person doesn’t pass any customer related info to the cook. Because, again, the cook has nothing to do with it.

We clearly define the boundaries and then let each person do what they should exactly do, what they are meant to do.

Well, what do we do, if we have customers who prefer subscription? They do not want to place the same order again and again. Instead, they just want to tell us about how often they want the order, once, and expects the food on all the scheduled times.

Recurring orders

Attempt #5: We aid the counter person with a reminder-clock. Say a customer wants Chicken Biryani every Friday night at 9 PM. A straight forward way is to have the customer come every Friday and make the order, get the food. But that isn’t cool, right?

Remember, we were asking the order-item, preferences and contact details from the customer? We simply start asking one more input: scheduling details. Counter person now uses her reminder-clock to handle all the orders. The stickies for the order are posted whenever the time comes. And then everything else continues the way it used to.

This is how the complete process looks now:

Counter person receives the order
She makes the note of the order in her register
She feeds the details to the reminder-clock
She let the customer know that order is placed
Now, whenever the time comes, the sticky is posted
And from there on, the same process continues: cook picks up the order and finishes the task and inform counter person about the same. The cook doesn't know anything about the reminder-clock. Cook just picks his sticky and starts cooking. What is the source of those stickies is not cook's business. In other words, even after this reminder-clock in place, from cook's POV nothing changes.

Next question: what do we do when our food truck becomes quite popular?

We can have a lot of orders coming in. Most of the times of the day, the sticky-area is going to be heavily loaded. The Cook is quite quick at doing his job, but one cook alone can only do so much.

Hiring more cooks

Attempt #6: Time to "scale". To handle the high number of orders, we simply hire more cooks! With multiple cooks working in parallel, we can handle the overwhelming number of orders easily.

Now we can witness one more advantage(apart from doing cooking asynchronously and thus not keeping the customer unattended for long) of decoupling the counter work and kitchen work: we need not hire all-rounders any more. If there are a lot of unprocessed stickies hanging, i.e., if kitchen is under heavy load, we can just hire more cooks. Similarly, if we grow to such a scale, that even counter load is becoming overwhelming, we can just hire more counter persons. The two areas can be scaled up/down independently of each other[3].

In fact, if we hire cooks on contract, we can scale "dynamically". When we expect more orders, say, during a festival season, we bring in more cooks temporarily, and then when the season is off, we can scale down to lesser number of cooks.

Also, we can keep some cooks dedicated to specific kind of orders. For example, if we have a juice section, we can have specific cook(s) with necessary resources with them to handle juice orders.

Another thing we can do is, we introduce members-only ordering. It means not everyone can order food at our food truck. Only the people who are registered with us can place an order. We can provide each member with an id at the time of registration which can be used later to identify them.

Having all of this in place this is how the updated flow of working inside the food truck will look like:

A counter person with a register and a reminder-clock, a sticky mechanism and a group of cooks with recipes can help us get on with our food truck business successfully!

Well, why did we discuss a food truck in an engineering blog post? To explain how Jobs Infrastructure works, we drew this analogy. Having this blog already read, it will be a walk-in-a-park to understand the upcoming technical blog where we discuss Jobs Infrastructure. In the meantime, play this game to test your understanding and let us know how much were you able to score in the comments section :)

If you enjoyed reading this blog and would like to work with us, do apply here.

Credits

https://neilpatel.com/blog/blog-post-image-guide/
Food Truck: Image by Ben Kerckx from Pixabay
Stickies: Image by Bruno Glätsch from Pixabay
Counter Person: Image by KDArtStudio from Pixabay
Cook: Image by Julien Tromeur from Pixabay
Recipe & Reminder-Clock: Image by OpenClipart-Vectors from Pixabay
Register: Image by Clker-Free-Vector-Images from Pixabay
High number of stickies: Image by Gerd Altmann from Pixabay

https://www.educaplay.com/

Fyle Stories

Discussion about this post