Designing a Text Sharing Service
High Level Design·beginner·~20 min read
- system-design
- pastebin
- text-sharing
- hld
What you'll learn
Problem Statement
Design a service where users can store and share plain text or code snippets. Users submit text content and receive a unique URL they can share. Anyone with the URL can view the content. Support features like expiration, private pastes,…
Requirements
Functional Requirements
1. Users can upload text content ("paste") and receive a unique shareable URL 2. Text-only content; no images or files 3. Pastes expire after a configurable duration (default: 30 days, max: custom) 4. Users can optionally set a custom al…
Non-Functional Requirements
1. High availability — links must always resolve 2. Low latency reads — paste content should load quickly 3. Durability — uploaded content must not be lost before expiration 4. Size limit — maximum 10 MB per paste
Extended Features
- Syntax highlighting (based on language tag) - View count per paste - User paste history (if authenticated) - Private pastes (require auth token to view) ---
Capacity Estimation
Traffic
| Metric | Calculation | Value | |--------|-------------|-------| | New pastes/day | Given | 1M | | Read:Write ratio | Given | 5:1 | | Reads/day | 1M × 5 | 5M | | Write QPS | 1M / 86,400 | ~12/s | | Read QPS | 5M / 86,400 | ~58/s |
Storage
| Metric | Calculation | Value | |--------|-------------|-------| | Average paste size | Given | 10 KB | | Daily content storage | 1M × 10 KB | 10 GB/day | | Annual content storage | 10 GB × 365 | 3.6 TB/year | | 10-year content storage…
Bandwidth
| Direction | Calculation | Rate | |-----------|-------------|------| | Incoming (writes) | 12/s × 10 KB | ~120 KB/s | | Outgoing (reads) | 58/s × 10 KB | ~580 KB/s | These bandwidth numbers are very modest — the service is storage-bound…
System APIs
---
High-Level Architecture
Why Separate Metadata from Content?
This is the defining architectural decision for a text sharing service: Concrete problems with Option A at 10-year scale: | Problem | Impact | |---------|--------| | DB backup | 36 TB backup = hours of downtime risk | | Replication | 36…
Design Evolution & Trade-offs
How this system grew from an MVP to what a production version looks like — and the choices you'd defend in an interview.
Stage 1 — MVP: One box, one database
The simplest thing that could possibly work for a text-sharing service. - A single API server (monolith) handles both POST /paste and GET /paste/{key}. - One relational database (Postgres or MySQL) with a single pastes table containing k…
Stage 2 — Scale-out: Multiple pods behind a load balancer
- API layer becomes stateless; N replicas behind an L7 load balancer. - No sticky sessions — the paste key IS the request identity, any pod can serve any read. - KGS gets extracted so pods don't fight over the sequence. - DB still holds…
Stage 4 — Bottleneck #2: Hot pastes destroy read latency
Even after separating content from metadata, a single viral paste can generate millions of reads per hour. Every read is: metadata DB → object storage. Both tiers get hammered, and object storage GET pricing (per-1000-requests) starts to…
Stage 5 — Bottleneck #3: Expiry cleanup at billion-record scale
Every paste has an ExpirationDate. At 3.65 billion pastes and default 30-day TTL, roughly 1 million pastes expire per day, and the system needs to reclaim ~10 GB/day of object storage plus ~100 MB/day of metadata rows. A naive DELETE FRO…
Stage 6 — Mature architecture
Everything from stages 2–5, wired together. This is what an interviewer expects on the whiteboard once you've walked through the tradeoffs. ---
Cost vs Complexity — When to Pick What
| Concern | MVP choice | Growth choice | Enterprise choice | |---------|-----------|---------------|-------------------| | Compute | Single VM, monolith API | K8s deployment, N stateless pods | Multi-region K8s with regional LBs | | Meta…
Migration Path (MVP → Enterprise)
The migration order matters — some steps unblock the next, and getting them backwards causes rework or downtime. 1. Extract content to object storage. Blocks nothing else if done right, but every subsequent step benefits from a slim meta…
Database Schema
Metadata Table (NoSQL / Key-Value Store)
Database Choice
Same reasoning as URL shortener, with one addition: | Factor | Decision | |--------|----------| | Billions of records | NoSQL scales horizontally | | Simple access pattern | Key → value (no joins) | | No relationships | No relational fea…
Key Generation Service (Reused Pattern)
The KGS design is identical to the URL shortener: Key recycling (bonus for text sharing): - When pastes expire and get cleaned up, their keys can be returned to unusedkeys - This is optional — 68.7B keys is more than enough for 3.65B pas…
Detailed Read Flow
---
Detailed Write Flow
Write Order: Content First or Metadata First?
| Order | Failure Mode | Impact | |-------|-------------|--------| | Content first (chosen) | Content exists, metadata doesn't | Orphaned blob (wasted storage, cleaned up later) | | Metadata first | Metadata exists, content doesn't | Bro…
Cleanup Service
Lazy Deletion (On Access)
Pros: Zero background overhead for non-accessed pastes Cons: Expired pastes that nobody reads stay forever (storage waste)
Active Deletion (Background Sweep)
Orphan Detection (Weekly)
---
Caching Strategy
Two-Layer Cache
Eviction Policy: LRU
- When cache is full, evict the least recently used entry - Linked HashMap implementation: O(1) read + O(1) eviction - On cache miss: fetch from source, insert into cache (evicting LRU if full) ---
Data Partitioning
Same strategies as URL shortener: | Strategy | Approach | Assessment | |----------|----------|-----------| | Range-based | First char of key | Unbalanced (letter frequency varies) | | Hash mod N | hash(key) % N | Adding servers reshuffle…
Security and Access Control
Visibility Levels
| Level | Behavior | |-------|----------| | Public | Anyone with the URL can view | | Unlisted | Not searchable, but URL holders can view | | Private | Requires authentication token (owner or explicitly shared) |
Implementation
Other Security
- Rate limiting: Per apidevkey - Content scanning: Optional check for malware/phishing URLs in paste content - Size validation: Reject > 10 MB immediately (don't buffer) - Input sanitization: Prevent XSS if pastes are rendered in browser…
Differences from URL Shortener (Design Reuse)
| Shared Pattern | Difference | |---------------|-----------| | KGS for key generation | Content stored in object storage (not inline) | | NoSQL metadata DB | Additional contentkey field pointing to blob | | LRU caching | Two-layer cache…
Summary: Key Architecture Decisions
| Decision | What it Solves | |----------|---------------| | Content in object storage | Keeps DB lean (365 GB vs 36 TB); enables independent scaling | | Metadata in NoSQL | Fast key-value lookups for billions of records | | KGS (same as…