System Design Interview (Food App)

A System Design interview with a Google engineer

Watch someone solve the design a free food app problem in an interview with a Google engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type
Design a free food app
Interview question
Distributing 6M burgers in 10mins. People will come and click on a button on App get My Free Burger. No one should get more than 1 burger. We should not promise more than 6M people that they will get a free burger.

Read more about the questions

Interview Feedback

Feedback about Immutable Penguin (the interviewee)

Advance this person to the next round?
Yes

How were their technical skills?
4/4
How was their problem solving ability?
4/4
What about their communication ability?
3/4

Distributing 6M burgers in 10mins. People will come and click on a button on App get My Free Burger. No one should get more than 1 burger. We should not promise more than 6M people that they will get a free burger.

Functional Requirements:
TC asked all good scoping questions related to the problem.
TC talked about what happened when 6M burgers were done.

Non-functional requirements:
Availability vs Consistency: Did not talk about this
Asked the latency expectancy.
Asked QPS. I asked if they can calculate from given information that there are 20M users.

Estimations:
TC skipped this entirely.

API Design:
Skipped this.

High Level Architecture:
TC identified that this system is write-heavy.
TC talked about read and write ratio.
TC talked about multiple write replicas.
TC talked about consistency.
TC identified that there could be concurrent requests from the same user.
TC talked about applying the Unique constraint on the DB.
TC also tried to cover the other requirement of not promising more than 6M burgers.
TC suggested that they would have a common counter. They identified that there is a need for concurrency control to avoid overpromising burgers.
TC suggested that locking with 35k qps is not practical.
TC then said that they can work on the distributed counts.
TC talked about version count and how we can see if the counter is always incrementing. TC had the distributed counters in distributed memory.
TC also talked about the approach where there would be a counter for each instance of the burger giveaway service. TC talked about the issue in the second approach that there could be an issue of losing the count if a server goes down. TC used the incremental counters. TC understood that there is additional coordination. TC could not come up with a way to avoid it.
I gave a hint towards the decremental counter. TC understood the fact that this could be easier with a lot less coordination. This shows TC is easy to communicate and can understand the feedback and hints pretty easily. TC understood the point that they can choose the in-memory database while storing the userIds. TC was able to identify the faults in the suggestions and design a really good system.

Database:
TC decided at last to have the DB in-memory.

Designing for Scale:
Sharding:
TC talked about sharding the database and talked about service discovery (Zookeeper).

Load Balancing:
TC used load balancing
Fault Tolerance:
TC talked about LB being a single point of failure.

Tips for Future Interview:

Feedback about Red Maelstrom (the interviewer)

Would you want to work with this person?
Yes

How excited would you be to work with them?
4/4
How good were the questions?
4/4
How helpful was your interviewer in guiding you to the solutions?
4/4

The interview was great. I learned some interesting things from it (e.g., using a decrementing counter). The feedback at the end was actionable and clear.