# System Design: Dating App Backend with Geospatial Search

### Interview Summary

**Problem type**
The Problem: Dating App Backend (Medium)

**Interview question**  
Design the backend for a dating application where users can log in, manage a profile, view nearby users, and maintain a favorites list. The system must support 1 million daily active users, prioritize availability for location-based queries, serve fresh real-time location data, and handle geospatial proximity searches efficiently—all without a matching system.

### Interview Feedback

**Feedback about Massive Lightning (the interviewee)**  
- Advance this person to the next round? Yes  
- How were their technical skills? 3/4  
- How was their problem-solving ability? 4/4  
- What about their communication ability? 3/4

> Strengths:  
> \* great breadth of knowledge & good understanding of backend distributed systems  
> \* largely able to focus on the interesting parts of the problem  
> \* quick at designing and discussing, so we were able to go through the whole problem which is great  
>  
> Areas for improvement:  
> \* it would be good to be able to provide more details about the technologies you use. e.g. when saying you're going to use redis, describe your key format and what the values will look like. For the DB, the schemas and queries could be more specific  
> \* find ways to demonstrate your depth of knowledge during the interview  
>  
> Advice:  
> \* try and keep your notes and ideas organized during the interview. Definitely worth using the whiteboard and I'd definitely recommend familiarizing yourself with the whiteboard tool Excalidraw. It's the one embedded for these practice interviews.  
> \* watch videos and read docs about the common technologies that you'd want to bring in (e.g. Postgres, Redis, Kafka, Kubernetes)  
> \* also bring lots of energy to interviews to keep the interviewer engaged, I thought you did pretty well with this, but it's something I think it's always worth reminding about

**Feedback about General Centurion (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 solution(s)? 4/4

> Great interviewer! Thought he cut the balance between collaborative and challenging quite well!

### Interview Transcript

**General Centurion**: Hello, good morning. Can you hear me?  
**Massive Lightning**: Yes. Hey, how are you doing?  
**General Centurion**: Not too bad, how about you?  
**Massive Lightning**: Doing good, doing good.  
**General Centurion**: Awesome, great. Okay, so I usually start with about like a quick little intro, maybe like under 1 minute each. And then we have the vast majority of time to do a practice question. Um, does that sound good?  
**Massive Lightning**: Uh, yeah, sounds great. Great.

**General Centurion**: Okay, so I'll start. Um, I've, uh, been at a bunch of different, uh, companies in, uh, industry, pretty backend focused, uh, moved more into infrastructure. Um, been at large places like Google, Stripe, uh, Airbnb, and then some smaller startups as well. Um, yeah, so that is me. And then with your intro, if you can also focus on what you're hoping to get out of this.  
**Massive Lightning**: That would be helpful. Yeah, so my name's [REDACTED]. I've been primarily working in startups for a little over a decade. Was a founder for like 2 years, was at [REDACTED] for like 2 years. Currently at a chip design startup. We build, we apply AI to mixed signal and analog chips. Trying to get back to, you know, basically trying to get like, you know, I'm trying to get prepared for interviewing at the [REDACTED]. So mostly, I haven't really done a lot of system interviews. So I just do some, I guess, like some dry runs to see how well I'm prepared.

### High-Level Design
The user will first update their profile through the profile service, which gets stored in a profile table. As the user moves, the app will periodically send updates to the location service to reflect their last known location. This allows for efficient queries to find nearby users corresponding to their preferences.

### API Endpoints
- `POST /profile` - Create a new user profile  
- `PUT /profile/{id}` - Update existing profile  
- `GET /nearby` - Retrieve a list of nearby users based on location

### Database Structure
**Profile Table**:  
- ID (UUID)  
- Name (string)  
- Email (string)  
- Preferences (JSON)  
- Location (Geospatial)  
- Created_At (datetime)

**Location Service**:  
- Active User Locations (Redis or DynamoDB for fast access)

### Overall Questions and Considerations
- **Availability vs. Consistency** - Balance strong consistency for user profiles with high availability for real-time queries.  
- **Caching** - Consider Redis or other caching layers for optimizing frequent read queries like nearby users.  
- **Cleanup Mechanism** - Implement cron jobs for stale entries in the database, ensuring privacy compliance like GDPR.

### Conclusion
Overall strength in broad system design but with room to deepen knowledge in SQL and caching mechanisms. Continued practice and refreshers in specific technologies will be beneficial.