# 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**  
- [Design a Free Food App](/content/questions/design-a-free-food-app/index.html)

### 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:**  
> - Add Estimation and API-Design steps after Non-Functional Requirements

#### 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.