Free lesson · System Design Interviews

Step 1: Functional and Non-Functional Requirements

Hard12 min readsystem-designinterview-prep

Pastebin is one of those interview questions that candidates underestimate. They think it's just "URL Shortener but with text content," and then they walk into a design that doesn't account for variable-size content, content rendering, abuse prevention, or the completely different storage economics that come from storing kilobytes-to-megabytes per entry instead of 300 bytes. I've seen this happen in interviews I've conducted - the candidate reuses their URL Shortener architecture verbatim and doesn't realise they're designing a system with 1,000x more storage per record. The interviewer notices.

Let me show you how to run the requirements conversation for Pastebin in a way that surfaces the differences from URL Shortener early, so your architecture reflects the actual problem instead of the problem you solved last week.

What Pastebin Actually Does

Pastebin is a content-sharing service. A user pastes text - code snippets, logs, configuration files, error messages, notes - and gets a unique URL they can share with anyone. The person visiting that URL sees the content rendered with syntax highlighting (if it's code) or as plain text.

flowchart LR
    CREATOR["Creator"] -->|"Pastes text content<br/>(code, logs, notes)"| SYSTEM["Pastebin<br/>Service"]
    SYSTEM -->|"Returns shareable URL:<br/>https://paste.ly/x7Kf2m"| CREATOR
    
    VIEWER["Viewer"] -->|"Visits URL"| SYSTEM
    SYSTEM -->|"Renders content with<br/>syntax highlighting"| VIEWER

Pastebin has two core flows. First, a creator pastes text content - code, logs, configuration files, or notes - and the system stores it and returns a shareable URL. Second, a viewer visits that URL and sees the content rendered with syntax highlighting if it's code, or as plain text otherwise. Unlike a URL shortener where the system just stores a mapping, Pastebin stores the actual content - which can be anywhere from a few bytes to several megabytes.

The critical difference from URL Shortener is right there in the diagram - Pastebin stores content, not just metadata. A URL mapping is 300 bytes. A paste can be 10 KB, 100 KB, or 10 MB. This single difference cascades through every layer of the architecture: storage estimation, caching strategy, bandwidth calculation, and database choice.

The Requirements Conversation

Let me walk you through exactly how I'd run this with an interviewer, question by question. I'm going to show you the questions I ask, the typical answers I get, and the design implications that fall out of each one.

Functional Requirements - What the System Does

Q: "What are the core operations?"

Two primary operations: create a paste (submit text, get a URL) and view a paste (visit the URL, see the content). Everything else - editing, deleting, searching - is secondary.

Q: "What kind of content are we storing?"

This is the question that separates good candidates from great ones. The answer determines your storage strategy.

Text content: code snippets, log files, configuration files, error messages, markdown notes, plain text. Not images, not binary files, not video. Text only. But "text only" can still be large - a full log file dump might be 5-10 MB. A database schema export might be 1 MB. Most pastes are small (under 100 KB), but the system needs to handle the occasional large paste.

Q: "Is there a size limit per paste?"

Almost always yes. Without a limit, someone will paste a 1 GB file and your storage costs explode. Typical limits:

For our design, let's assume a 10 MB maximum per paste with the average paste being 10 KB. This 1,000x range between average and maximum is important - it means you can't treat every paste equally in your caching and storage strategy.

Q: "Do we need syntax highlighting?"

Yes - this is a core user expectation. The creator specifies a language (Python, Java, JSON, YAML, etc.) and the viewer sees the content with colour-coded syntax. This is a front-end concern mostly, but it affects the API (you need to store and return the language type) and the content rendering pipeline.

Q: "Do pastes expire?"

Yes. Users should be able to set an expiration: 10 minutes, 1 hour, 1 day, 1 week, 1 month, never (or a default like 30 days for anonymous users). This creates a cleanup requirement and affects storage growth calculations.

Expiration models I've seen in interviews:

Q: "Can pastes be edited after creation?"

This is a fork-in-the-road question. If pastes are immutable (write-once, read-many), the architecture is simpler - you can cache aggressively because content never changes. If pastes are editable, you need cache invalidation, versioning, and potentially optimistic concurrency control.

Most interviewers say pastes are immutable - once created, the content doesn't change. The creator can delete a paste but not modify it. This is a deliberate simplification that makes the system much easier to design in 45 minutes.

Tip: Always ask the edit question. If the interviewer says "yes, pastes can be edited," you've uncovered a significant design challenge - cache invalidation for large content blobs. If they say "no," you've confirmed a simplification that makes your cache strategy cleaner. Either way, asking the question shows you're thinking about the implications.

Q: "Do we need user accounts, or is this anonymous?"

Both. Anonymous users can create and view pastes. Registered users get additional features: viewing their paste history, managing (deleting) their pastes, higher size limits, and longer or permanent expiration.

Q: "Should pastes be public or private?"

This matters for access control. Three visibility levels:

For our design, let's support public and unlisted (the default). Private pastes are a premium feature we'll scope out.

The Functional Requirements Summary

Important: Functional Requirements (confirmed with interviewer):

1. Create Paste: User submits text content (up to 10 MB) and receives a unique shareable URL
2. View Paste: Anyone with the URL can view the content with syntax highlighting
3. Paste Expiration: User-selectable expiration (10 min, 1 hour, 1 day, 1 week, 1 month, never)
4. Syntax Highlighting: Creator specifies language; content rendered with colour-coded syntax
5. Delete Paste: Creator can delete their paste (requires the delete token returned at creation)

Out of Scope (explicitly deferred):

• Editing pastes after creation (immutable content)
• Full-text search across pastes
• Paste forking/cloning
• User accounts (simplified to anonymous + optional delete token)
• Private pastes requiring authentication
• Paste versioning/history
• Real-time collaborative editing (that's Google Docs, not Pastebin)
• Image/binary file uploads

Non-Functional Requirements - How the System Performs

Here's where Pastebin diverges significantly from URL Shortener. The content size changes everything.

Scale

Q: "How many pastes are created per day?"

Pastebin gets far less traffic than a URL shortener. Pastebin.com receives roughly 2-3 million pastes per day. Let's use 5 million new pastes per day as our design target - slightly above the current market leader to give ourselves headroom.

Q: "What's the read-to-write ratio?"

Pastes are typically viewed more often than they're created, but not nearly as heavily as URL shortener redirects. A paste is created once and viewed maybe 5-50 times on average. Let's assume a 5:1 read-to-write ratio - much lower than URL Shortener's 100:1.

This gives us:

• Writes: 5 million/day → ~58/sec average, ~175/sec peak
• Reads: 25 million/day → ~290/sec average, ~870/sec peak

flowchart LR
    subgraph WRITES["Write Path (~58 QPS avg)"]
        W["Create paste<br/>(5 million/day)"]
    end
    
    subgraph READS["Read Path (~290 QPS avg)"]
        R["View paste<br/>(25 million/day)"]
    end
    
    WRITES ---|"5:1 ratio"| READS
    
    NOTE["Much lower QPS than URL Shortener.<br/>The challenge isn't QPS —<br/>it's content size per request."]

Traffic estimation for Pastebin. Write QPS is about 58 average peaking at 175 - far lower than URL Shortener. Read QPS is about 290 average peaking at 870. The read-to-write ratio is 5-to-1, much lower than URL Shortener's 100-to-1. The design challenge for Pastebin isn't handling high QPS - it's handling variable-size content that ranges from a few bytes to 10 megabytes per request. The bandwidth and storage implications of large content are what drive the architecture, not the request rate.

Notice something? The QPS is much lower than URL Shortener. At 290 reads/sec, a single server can handle this easily. The challenge for Pastebin isn't request throughput - it's content size and bandwidth. Each response returns the full paste content, which could be 10 KB to 10 MB. That's the bottleneck that shapes the architecture.

Interview: What to say: "Pastebin is a fundamentally different scaling problem from URL Shortener. URL Shortener is QPS-bound - tiny payloads at massive request rates. Pastebin is bandwidth-bound - moderate request rates but much larger payloads. A single redirect is 300 bytes; a single paste view could be 10 MB. That's a 30,000x difference in response size, and it completely changes the caching and storage strategy."

Latency

Q: "What's the latency requirement for viewing a paste?"

Viewing a paste involves rendering potentially large content with syntax highlighting. Users accept slightly more latency than a URL redirect:

• Paste viewing: <200ms p99 for content delivery (syntax highlighting happens client-side)
• Paste creation: <500ms p99 (user is actively waiting, but creating content is inherently a slower action)

Content Size Distribution

This is unique to Pastebin and doesn't apply to URL Shortener. Understanding the size distribution drives your caching strategy:

70% of pastes are under 10 KB. This is important for caching - small pastes fit comfortably in Redis. Large pastes (the 10% above 100 KB) should be served directly from object storage, not cached in memory.

Availability and Durability

• Availability: 99.9% is acceptable (compared to URL Shortener's 99.99%). Pastebin is a convenience tool, not mission-critical infrastructure. A few minutes of downtime per month is tolerable.
• Durability: Once a paste is created, losing it is unacceptable (until it expires). Users share paste URLs in documentation, Stack Overflow answers, and chat messages. Broken links erode trust.

The Non-Functional Requirements Summary

Important: Non-Functional Requirements:

Requirement	Target	Implication
Write throughput	~58 QPS avg, ~175 peak	Very manageable - single server can handle this
Read throughput	~290 QPS avg, ~870 peak	Moderate - not QPS-bound
Content size	Avg 10 KB, max 10 MB	Bandwidth-bound, not QPS-bound
View latency	<200ms p99	CDN + cache for small pastes, object storage for large
Creation latency	<500ms p99	Acceptable - content upload takes time
Availability	99.9%	Standard - not mission-critical
Durability	No data loss before expiration	Replicated storage
Storage	5 years retention with expiration	~180 TB total (see estimation)

How Pastebin Requirements Differ from URL Shortener

This comparison is interview gold - if you've already discussed URL Shortener, drawing the contrast shows depth of understanding.

Warning: Don't recycle your URL Shortener architecture. The most common mistake I see is candidates who just swap "URL mapping" for "paste content" in their URL Shortener design. The content size difference means you need object storage (S3) instead of just a database, a CDN for content delivery, size-aware caching, and bandwidth-aware scaling. If your Pastebin architecture looks identical to your URL Shortener architecture, something is wrong.

Requirements Drive Architecture - The Preview

Just as we did with URL Shortener, let's map each requirement to the architecture decision it drives:

The two biggest differences from URL Shortener's architecture:

1. Object storage (S3) is the primary content store - not a relational database. You don't put 10 MB blobs in PostgreSQL rows. You store the blob in S3 and keep a metadata row in the database that points to it.

2. CDN is more valuable here than for URL Shortener. A URL Shortener redirect is 300 bytes - CDN savings are minimal. A Pastebin paste is 10 KB average - CDN caching provides meaningful bandwidth offloading and latency improvement for global users.

Key Takeaways

1. Pastebin is bandwidth-bound, not QPS-bound. At 290 read QPS, request throughput is easy. But each response carries 10 KB to 10 MB of content. The architecture must optimise for content delivery, not for handling millions of tiny requests.

2. Content size varies by 10,000x (1 KB to 10 MB). This means you can't treat all pastes the same way. Small pastes can be cached in Redis. Large pastes should be served directly from object storage or CDN. A one-size-fits-all caching strategy wastes memory or misses the most common case.

3. Object storage, not database, for content. Storing 10 MB blobs in PostgreSQL is technically possible but operationally painful - it bloats the database, makes backups slow, and prevents efficient use of CDN. Store content in S3 and metadata in PostgreSQL.

4. Immutable content is a deliberate design simplification. If pastes can't be edited after creation, you can cache aggressively without worrying about invalidation. Always confirm this assumption with the interviewer.

5. Pastes expire - storage is not monotonically growing. Unlike URL Shortener where every mapping matters forever, Pastebin content has a finite lifetime. This means your long-term storage estimate is much lower than "daily volume × years."

6. The URL Shortener comparison is a senior signal. If you can articulate why Pastebin's architecture must differ from URL Shortener's - content size, storage type, bandwidth vs QPS - you've demonstrated that you design from requirements, not from templates.

Exercise: Exercise 1: Run the requirements conversation for a "code collaboration" variant of Pastebin where multiple users can edit the same paste simultaneously (like a lightweight Google Docs for code). How do the functional requirements change? What new non-functional requirements emerge? (Hint: conflict resolution, operational transforms, WebSocket connections for real-time sync.)

Exercise 2: The interviewer asks: "What if we need to support binary file uploads - images, PDFs, zip files - up to 100 MB?" How does this change the content size distribution, storage estimation, and content delivery strategy? Does syntax highlighting still apply? What MIME type handling is needed?

Exercise 3: Design the requirements for an enterprise version of Pastebin used internally at a company with 50,000 employees. What new requirements emerge around access control, audit logging, data retention policies, compliance, and integration with SSO? How do the non-functional requirements differ from the public version?

Back to System Design Interviews