May 5, 2022 7:00 PM PDT
This document summarizes the mock system design interview focused on creating a TinyURL service. The interview covered functional and non-functional requirements, system design considerations, and feedback from the interviewer and audience.
Requirements
Functional Requirements
- Convert long URLs to short URLs.
- Each long URL should map to only one short URL.
- Short URLs should be as brief as possible.
- Allowed characters include upper and lower case letters and numbers.
Non-Functional Requirements
- The system must handle 100 million URL generations per day.
- Long URLs can be up to 100 bytes.
- Short URLs should be 10 bytes.
- The system will require significant read operations compared to writes.
System Design
Database Design
- Utilize a NoSQL database with key-value pairs for scalability and easy lookups.
- Two tables can be created: one mapping long URLs to short URLs and another mapping short URLs back to long URLs.
- Implement one write server and multiple read servers.
External APIs
- POST API for generating short URLs from long URLs.
- GET API for translating short URLs back into long URLs.
Handling Collisions
- To ensure unique short URLs, check the generated hash against the database. If a collision occurs, append a random value and retry.
- Use a hash function combining the timestamp and long URL.
Load Balancing and Caching
- Implement a load balancer to distribute traffic to read servers.
- Utilize caching to store recently queried short URLs to reduce database load.
Read and Write Operations
- Use multiple databases to handle read requests, with one master database for writes and multiple slave databases for reads.
- Employ eventual consistency to propagate mappings to read replicas.
Security Measures
- Implement a rate limiter on the client side to prevent abuse and attacks.
- Consider using algorithms like sliding window or token bucket for request management.
Feedback
Interviewer Feedback
- Communication and soft skills were noted as strengths.
- Hard skills require improvement, particularly in the application of basic building blocks.
- Emphasized the importance of understanding API design, high-level design, and database consistency.
Audience Feedback
- Suggested improvements in requirement gathering, particularly in handling edge cases such as missing URLs or malicious content.
- Noted that the interview felt reactive and encouraged interviewees to drive the discussion more actively.
- Discussed the importance of ensuring 1-1 mapping in the database and the use of materialized views or two-phase commit (2PC) for consistency.
Key Points
- Ensure 1-1 mapping in the database to maintain consistency.
- Consider using UUIDs for generating short URLs.
- Address potential issues with data center failures as a bonus feature.
- Implement expiration policies for cache management, such as a 5-year TTL.
Technical Considerations
- Redis can be used for caching with support for transactions.
- MySQL may require sharding to handle high write volumes.
- Discussed the implications of using different databases, such as DynamoDB and Cassandra, for scalability and performance.