Requirements

Functional (what the system does):

• The core loop: user gives a long URL → system returns a short alias
• The reverse: someone visits the short alias → system redirects to the original long URL
• Think about whether you want to add anything beyond the core — e.g., custom aliases, expiration, or analytics. For a "simple" TinyURL, keep it minimal; you can mention extras as stretch goals.

Non-Functional (how well it does it):

• High availability — a redirect service that's down is useless; every lookup should succeed
• Low latency — redirects are on the user's critical path; every extra millisecond is felt
• Horizontal scalability — you'll be handling millions of URLs and reads, so the design must scale out, not up

A good exercise: write these as if you were an engineer explaining to a product manager. Then ask yourself — for each requirement, how will my design actually prove it? That connection is what separates a list from a design.

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

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

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.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

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.