Requirements
Functional Requirements:
- Create a short URL for a given long URL.
- Return the long URL associated with a given short URL.
- Treating this as a product like TinyUrl.com
- URLs are auto deleted after no activity.
- Do not allow URLs to be changed once created. It's write only.
- Tiny url consisting of A-Z, a-z and 0-9 (62 chars, 8 chars max).
- Allow for paid version which has additional features:
- Allow for custom user defined URLs.
- Allow for metrics to be tracked for generated URLs.
Non-Functional Requirements:
- List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
- Fast Re-routing of tiny URL, low latency.
- Read Heavy System. Need Cache.
- Slow write. Throttle support to prevent spam.
- Paid features:
- Requires validation of profanity. (Dict + AI Based).
- Basic metrics:
- How many reroutes.
API Design
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
Let's start with few resources and crud APIs for those:
-> User
-> URL
Core APIs:
POST /create/URL
-> If authenticated user is signed in, then url is registered against the user.
GET tinyurl.com/
Authenticated APIs:
DELETE /delete/tinurl
POST /createcustom/URL | body takes in customId.
POST: /user/create
GET /user/metrics
High-Level Design
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
There are few high level design components:
1) L7 Load Balancer -> This decides based on the incoming request where the request would go. It's backed by web server which serves the TIny URL Website where customer can create the URL etc. The standard path goes to webserver which responds with standard webpages. But the /
3) The webserver provides webpages and manages authentication through the auth server.
2) Get TinyURL Mircro service basically uses cache fleet to quickly look up if there a tiny url otherwise uses Quick NO SQL Look up and store it in cache. In addition, it also send a metric to a queue that is used to buffer the data point before it's written to a db.
3) The write path goes through the write tiny URL Micro service which handles both creating tiny URLs also user management.
4) Tiny URL generation service is responsible for quickly generating the tiny URL. It simply return a randomly generated URL using our scheme of a-zA-Z and 0-9. It provide apis that optionally take in custom url and checks with Profanity AI Service which uses Dict + Gen AI model to figure out if tiny url can be created.
5) The NO SQL DB uses simple tinyURL -> Actual URL Mapping, created date (maybe for secondary indexes).
6) The User DB has few things -> Username, Salted/HashPassword, Membership, Tiny URLs that this user manages.
7) The Auto Delete is a batch system which periodically runs to scan the No SQL DB (Like using maybe secondary indexes or on replicas) to figure out which tinyURL should be deleted. It also looks at Time series/metrics db to figure out when a URL should be deleted.
Detailed Component Design
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
Tiny URL Generation Service uses randomly generated 8 chars from a-z A-Z 0-9 chars. It keeps generating few in background and keep them hot. When a request comes it dispenses a generated ID.
Tiny URL server uses a simply micro service to quickly look at cache and if it find the value return the http 302 code with the redirected actual URL. If cache is no found then no sql db is used to check the url. Also a metric is emitted for time series to make sure the URL being access is recorded for auto delete service.