Requirements

Functional Requirements:

• Users need to be able to create accounts and login. I will assume we have an IDP or some kind of auth system already. We're not in the business of building authentication.
• Users need to be able to create shortlinks (Create a short URL for a given long URL.)
• Users need to be able to view shortlinks they've created
• Users need to be able to edit shortlinks
• Users need to be able to delete shortlinks

• Anonymous users need to be redirected to a long url when visiting a valid shortlink (Return the long URL associated with a given short URL)

Non-Functional Requirements:

• Average TPS = 10k
• Peak TPS = 100k

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

Administrative endpoints

• POST /api/v1/shortlinks - create new link
• GET /api/v1/shortlinks - returns paginated list of links
• GET /api/v1/shortlinks/{id} - returns single link details
• PUT /api/v1/shortlinks/{id}
• DELETE /api/v1/shortlinks/{id}

Main endpoint

• GET /{shortlink} - returns 302 redirect

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.

I think the basic design in the diagram could suffice. The administrative endpoints should be fairly low volume. I don't foresee users creating a lot of shortlinks all the time. These endpoints should simply take the CRUD operations and utilize the database directly. For the database I think we could use postgres. It's a great general purpose database an I know it well. The main endpoint will need to scale though. There are a few approaches we could take, but I think to start, we could just use the web server and implement a LRU cache. For big events this could provide a very fast response where many users are requesting the same shortlink because it would be able to skip going to the database and return an in-memory redirect url. For shortlinks not in the LRU cache, it would go to the database.

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.

We should be able to scale our servers out horizontally pretty easily as well. We could set up autoscaling and put a load balancer in front of them. And since our database would not be used for the majority of requests, it should be able to keep up pretty easily.

If we need to scale our database for some reason, we could put readonly replicas in place. Since there really isn't a requirement that the replication complete quickly, this should work nicely. For example, if the replicas take 30 seconds to be consistent, this should be fine.

If we're worried about spamming with bad shortlinks, we could put some kind of firewall in front of the ingress that could automatically block requests from IPs where they've made 10 bad requests in a minute, or something along those lines.