69:T894,// =============================== // URL Shortener Core API // =============================== // 1. Create Short URL // POST /api/v1/shorten interface CreateShortUrlRequest { longUrl: string; // Required: destination URL customAlias?: string; // Optional: user-requested short code expiresAt?: string; // Optional: ISO timestamp for expiration title?: string; // Optional: descriptive title tags?: string[]; // Optional: categorization tags } interface CreateShortUrlResponse { shortCode: string; // Generated short code (e.g., "a7Xk2B") shortUrl: string; // Full short URL (e.g., "https://short.url/a7Xk2B") longUrl: string; // Original URL (echoed back) createdAt: string; // ISO timestamp expiresAt?: string; // Expiration if set } // 2. Redirect (Browser-facing, not API) // GET /{shortCode} // Response: 301/302 Redirect to longUrl // Headers: Location: {longUrl} // 3. Get URL Info // GET /api/v1/urls/{shortCode} interface GetUrlInfoResponse { shortCode: string; shortUrl: string; longUrl: string; createdAt: string; expiresAt?: string; clicks: number; // Total click count status: "active" | "expired" | "disabled"; } // 4. Get URL Analytics // GET /api/v1/urls/{shortCode}/analytics interface GetAnalyticsRequest { startDate: string; // ISO date endDate: string; // ISO date granularity: "hour" | "day" | "week" | "month"; } interface GetAnalyticsResponse { shortCode: string; totalClicks: number; uniqueClicks: number; clicksByDate: { date: string; clicks: number }[]; clicksByCountry: { country: string; clicks: number }[]; clicksByReferrer: { referrer: string; clicks: number }[]; clicksByDevice: { device: string; clicks: number }[]; } // 5. Update Short URL // PATCH /api/v1/urls/{shortCode} interface UpdateUrlRequest { longUrl?: string; // Update destination expiresAt?: string; // Update expiration disabled?: boolean; // Enable/disable } // 6. Delete Short URL // DELETE /api/v1/urls/{shortCode} // Response: 204 No Content61:{"json":{"id":"seed_20482b2d798d7239442d6dc43b41af08","slug":"url-shortener","category":"System Design (HLD)","topic":"URL Shortener","title":"Designing a URL Shortener","description":"Master the art of designing a highly scalable URL shortening service. Learn URL encoding strategies, redirect optimization, analytics collection, custom URL handling, and techniques for scaling to billions of reads per day.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_7405c043bb03088d79fc6d534d4bca07","title":"Requirements: Shorten, Redirect, Analytics","order":0,"content":[{"id":"opening-hook","title":"The Power of Short URLs","content":[{"data":{"content":"In the age of social media, where every character counts and attention spans are measured in milliseconds, URL shorteners have become critical infrastructure for the internet. Services like Bitly, TinyURL, and Twitter's t.co handle **billions of redirects daily**, powering everything from marketing campaigns to tweet embeds.\n\nWhat appears to be a trivially simple service—converting a long URL into a short one—is actually a fascinating system design challenge that touches on nearly every core distributed systems concept: high-availability storage, extreme read scalability, low-latency serving, analytics at scale, and security considerations.\n\nIn this module, we'll design a URL shortening service capable of handling **100 million URL creations per day** and **1 billion redirects per day**—a scale that requires careful architectural thinking from the ground up."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the complete functional and non-functional requirements for a URL shortener at scale. You'll learn to systematically decompose the problem, identify the three core operations (shorten, redirect, analytics), and establish the constraints that will drive all subsequent design decisions.","variant":"info"},"type":"callout"}]},{"id":"problem-domain","title":"Understanding the Problem Domain","content":[{"data":{"content":"Before diving into requirements, let's thoroughly understand what a URL shortener actually does and why it exists. A URL shortener is a service that:\n\n1. **Accepts a long URL** (e.g., `https://www.example.com/products/category/electronics/laptops?brand=dell&sort=price&page=12`)\n2. **Generates a short, unique alias** (e.g., `https://short.url/a7Xk2B`)\n3. **Redirects visitors** from the short URL to the original long URL\n4. **Collects analytics** about those redirects (who clicked, when, from where)\n\n**Why do URL shorteners exist?**"},"type":"text"},{"data":{"items":["**Character Limit Constraints** — Platforms like Twitter (now X) historically had strict character limits. A 200-character URL in a 280-character tweet leaves little room for content. URL shorteners compress URLs to 15-25 characters.","**Readability and Shareability** — Long URLs with query parameters are visually unappealing and hard to share verbally or in print. Short URLs are clean and memorable.","**Tracking and Analytics** — Marketing teams need to measure which campaigns, channels, and content drive traffic. URL shorteners provide click tracking without modifying the destination site.","**Link Management** — Enterprise users need to update destination URLs without changing what's already been shared. URL shorteners enable this indirection layer.","**Security and Privacy** — Services can mask destination URLs (for affiliate links) or validate link safety before redirect.","**Branding** — Custom domains (e.g., `amzn.to`, `youtu.be`) reinforce brand identity while providing URL shortening."],"title":{"icon":"Layers","text":"Primary Use Cases for URL Shorteners","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Info","title":"Scale of Major URL Shorteners","content":"Bitly processes over 10 billion clicks per month. Twitter's t.co wraps every link in every tweet—hundreds of millions of tweets per day. TinyURL has been running since 2002 with billions of redirects. These services demonstrate that URL shortening is serious infrastructure, not a toy project.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"functional-requirements","title":"Functional Requirements Analysis","content":[{"data":{"content":"Functional requirements define **what the system does**—the features and capabilities it must provide. For a URL shortener, we identify three core operations plus several supporting features.\n\n## Core Operation 1: URL Shortening\n\nThe primary function is accepting a long URL and returning a short one. Let's decompose this thoroughly:"},"type":"text"},{"data":{"rows":[["Input Validation","Accept valid HTTP/HTTPS URLs; reject malformed URLs, local addresses, forbidden domains","Need URL parsing, validation logic, blocklist management"],["Short Code Generation","Generate unique 6-8 character alphanumeric codes","Need encoding scheme, collision handling, uniqueness guarantees"],["Custom Aliases","Allow users to request specific short codes (premium feature)","Need availability checking, reservation system, alias validation"],["Expiration Support","Optional TTL (time-to-live) for short URLs","Need expiration tracking, cleanup jobs, expiration metadata storage"],["User Association","Link short URLs to user accounts (for management)","Need authentication, user-URL mapping, access control"],["Duplicate Detection","Same long URL → same short code (or new one based on policy)","Need efficient lookup by long URL, policy configuration"]],"caption":"URL Shortening Feature Decomposition","headers":["Feature Aspect","Requirements","Design Implications"]},"type":"table"},{"data":{"content":"## Core Operation 2: URL Redirection\n\nThe most frequent operation—redirecting users from short URLs to original destinations. This must be extremely fast and highly available:"},"type":"text"},{"data":{"items":["**HTTP Redirect Response** — Return 301 (permanent) or 302 (temporary) redirect with the original URL. Choice affects browser caching and SEO.","**Sub-50ms Latency** — Users should perceive instant redirects. Cache hits must be <10ms; cache misses <50ms.","**High Availability** — 99.99% uptime minimum. Redirects failing directly impacts all users of those links.","**Graceful Degradation** — Show meaningful error pages for expired, deleted, or malicious links.","**Preview Mode** — Optional landing page showing destination URL before redirect (security feature).","**Mobile Deep Links** — Support redirecting to app-specific URLs on mobile devices."],"title":{"icon":"ArrowRight","text":"Redirection Requirements","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"## Core Operation 3: Analytics Collection\n\nEvery redirect represents a data point. Analytics transform URL shorteners from simple utilities into valuable marketing infrastructure:"},"type":"text"},{"data":{"items":["**Click Counting** — Total clicks per short URL, with real-time or near-real-time updates.","**Temporal Distribution** — Clicks over time (hourly, daily, weekly aggregations) for trend analysis.","**Geographic Data** — Country, region, city derived from IP address geolocation.","**Referrer Information** — Which sites/platforms referred the traffic (Twitter, email, direct, etc.).","**Device/Browser Data** — Device type, OS, browser from User-Agent parsing.","**Unique vs. Total Clicks** — Distinguish unique visitors from repeat clicks (requires session/fingerprint tracking)."],"title":{"icon":"BarChart3","text":"Analytics Data Requirements","type":"icon","color":"secondary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"AlertCircle","title":"Analytics Cannot Block Redirects","content":"Critical design constraint: analytics collection must never delay or block redirects. Users click links expecting instant response. If analytics processing is slow or failing, redirects must still work. This implies asynchronous analytics processing.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"supporting-features","title":"Supporting Features and Edge Cases","content":[{"data":{"content":"Beyond core operations, production URL shorteners require numerous supporting features. These often distinguish basic hobby projects from enterprise-grade systems:"},"type":"text"},{"data":{"rows":[["User Management","Registration, authentication, API keys, rate limits per user","Enable personalized experiences, prevent abuse, monetization"],["Link Management","Edit destination URLs, enable/disable links, bulk operations","Enterprise users need workflow tools, not just URL generation"],["API Access","REST/GraphQL APIs with authentication, webhooks for events","Programmatic access for integration with marketing tools, CMS systems"],["Custom Domains","Users bring their own domains (e.g., link.company.com)","Branding, trust, enterprise requirement"],["QR Code Generation","Generate QR codes for short URLs","Physical-to-digital bridging for marketing materials"],["Security Features","Phishing detection, malware scanning, spam prevention","Protect users, maintain service reputation, legal compliance"]],"caption":"Supporting Feature Requirements","headers":["Feature Category","Capabilities","Why It Matters"]},"type":"table"},{"data":{"content":"## Critical Edge Cases to Handle\n\nRobust system design anticipates edge cases before they become production incidents:"},"type":"text"},{"data":{"items":["**Expired Links** — What happens when a TTL-limited link expires? 404? Custom message? Redirect to homepage?","**Deleted Links** — Should short codes be recycled? (Generally no—prevents hijacking known links)","**Circular Redirects** — User shortens a short URL that eventually points back. Must detect and prevent loops.","**Destination Site Down** — Should we detect and warn? Cache last-known-good destination?","**Concurrent Custom Alias Requests** — Two users request same custom alias simultaneously. Conflict resolution needed.","**URL Changes** — Long URL with tracking params changes slightly. Same short code or new one?","**Unicode/IDN URLs** — Support for international domain names and Unicode paths.","**Maximum URL Length** — Define limits on input URL length (2000 chars? 8000 chars?)."],"title":{"icon":"AlertTriangle","text":"Edge Cases Requiring Special Handling","type":"icon","color":"accent","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"icon":"Lightbulb","title":"Scope Management in Interviews","content":"In a system design interview, you won't cover all features. List the ones you're aware of, then explicitly scope: 'For this discussion, let's focus on core shortening, redirection, and basic analytics, deferring custom domains and QR codes.' This shows awareness without scope creep.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"non-functional-requirements","title":"Non-Functional Requirements","content":[{"data":{"content":"Non-functional requirements define **how well the system works**—its quality attributes. For a URL shortener, these are particularly critical because the service must be fast, available, and scalable to be useful at all.\n\n## Scalability Requirements\n\nLet's establish concrete scale targets that will drive architecture decisions:"},"type":"text"},{"data":{"rows":[["URL creations per day","100 million (1,157 per second avg, 5,000 peak)","Write-heavy during URL creation, needs efficient storage"],["Redirects per day","1 billion (11,574 per second avg, 50,000+ peak)","Read-heavy overall; 10:1 read/write ratio is conservative"],["Total URLs stored","100 billion over 10 years","Massive storage requirements; data retention policies needed"],["Analytics events per day","1 billion+ (one per redirect)","High-throughput event streaming; aggregate storage"],["Geographic distribution","Global (6 continents)","Multi-region deployment; data residency considerations"]],"caption":"Scale Targets for URL Shortener Design","headers":["Metric","Target Value","Implication"]},"type":"table"},{"data":{"content":"## Latency Requirements\n\nURL shorteners are in the critical path for every click. Slow redirects directly impact user experience and can increase bounce rates:"},"type":"text"},{"data":{"items":["**URL Creation**: <200ms end-to-end (acceptable for write operations)","**Redirect (cache hit)**: <10ms at server (before network transit)","**Redirect (cache miss)**: <50ms at server including database lookup","**Redirect P99**: <100ms (99th percentile must not exceed this)","**Analytics query**: <500ms for standard reports; <5s for complex analytics"],"title":{"icon":"Zap","text":"Latency Targets","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"## Availability and Reliability Requirements\n\nA URL shortener being down means every link using it is broken—potentially millions of links embedded across the internet:"},"type":"text"},{"data":{"rows":[["Redirect availability","99.99% (four nines)","~52 minutes downtime per year"],["URL creation availability","99.9% (three nines)","~8.7 hours downtime per year"],["Analytics availability","99.5%","More tolerant; eventual consistency acceptable"],["Data durability","99.999999999% (eleven nines)","Zero data loss acceptable; use replication"],["Disaster recovery","RPO: 1 minute, RTO: 5 minutes","Minimal data loss, fast recovery"]],"caption":"Availability Requirements","headers":["Aspect","Requirement","Translation"]},"type":"table"},{"data":{"icon":"Info","title":"Read vs. Write Availability Trade-offs","content":"Notice that redirect availability (99.99%) is higher than creation availability (99.9%). This is intentional—reads are far more critical and frequent. During partial outages, we might disable URL creation while maintaining redirects. This matches business priority: existing links must work.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"capacity-estimation","title":"Back-of-Envelope Capacity Estimation","content":[{"data":{"content":"Rough capacity estimation helps validate whether our design decisions are feasible and identifies the primary resource constraints.\n\n## Storage Estimation\n\nLet's calculate how much storage we need for URL mappings:"},"type":"text"},{"data":{"code":"URL Storage Calculation\n=======================\n\nData per URL entry:\n- Short code: 7 bytes (6-8 chars, let's use 7)\n- Long URL: 200 bytes (average, can be up to 2KB)\n- Creation timestamp: 8 bytes\n- Expiration time: 8 bytes (optional)\n- User ID: 8 bytes (optional)\n- Click count: 8 bytes\n- Flags/metadata: 10 bytes\n-----------------------------------\nTotal per URL: ~250 bytes\n\nURLs created per day: 100,000,000\nBytes per day: 100M × 250 = 25 GB/day\nBytes per year: 25 GB × 365 = 9.125 TB/year\nBytes over 10 years: ~91 TB for URL mappings alone\n\nWith indexes and replication (3x):\nTotal storage (10 years): ~275 TB + indexes ≈ 400 TB","fileName":"storage_estimation.txt","language":"plaintext"},"type":"code"},{"data":{"content":"## Bandwidth Estimation\n\nLet's estimate network bandwidth for redirection traffic:"},"type":"text"},{"data":{"code":"Bandwidth Calculation\n=====================\n\nRedirects per day: 1,000,000,000 (1 billion)\nRedirects per second (avg): 1B / 86,400 ≈ 11,574 RPS\nRedirects per second (peak): ~50,000 RPS (4-5x average)\n\nRequest size (incoming):\n- HTTP headers: 500 bytes (average)\n- Short URL in path: 20 bytes\nTotal incoming: ~520 bytes per request\n\nResponse size (outgoing):\n- HTTP 301/302 headers: 300 bytes\n- Location header: 200 bytes (destination URL)\n- Body (minimal): 100 bytes\nTotal outgoing: ~600 bytes per response\n\nIncoming bandwidth:\n- Average: 11,574 × 520 bytes = 6.0 MB/s\n- Peak: 50,000 × 520 bytes = 26 MB/s\n\nOutgoing bandwidth:\n- Average: 11,574 × 600 bytes = 6.9 MB/s\n- Peak: 50,000 × 600 bytes = 30 MB/s\n\nTotal peak bandwidth: ~60 MB/s (~480 Mbps)\nNote: This is modest; network is NOT the bottleneck.","fileName":"bandwidth_estimation.txt","language":"plaintext"},"type":"code"},{"data":{"content":"## Cache Estimation\n\nCaching is critical for achieving low-latency redirects. Let's estimate cache requirements:"},"type":"text"},{"data":{"code":"Cache Sizing Calculation\n========================\n\nObservation: URL access follows power-law distribution\n- 20% of URLs receive 80% of traffic\n- Top 1% of URLs receive ~50% of traffic\n\nTo achieve 90%+ cache hit rate:\n- Cache the top 10-20% of URLs by access frequency\n\nURLs created per day: 100,000,000\nActive URLs (accessed in last 30 days): ~500,000,000\nTop 20% active URLs: 100,000,000\n\nMemory per cached entry:\n- Short code: 7 bytes\n- Long URL: 200 bytes\n- Metadata (TTL, etc): 50 bytes\n- Redis overhead: 50 bytes\nTotal: ~300 bytes\n\nCache size for top 20%:\n100M × 300 bytes = 30 GB per region\n\nWith 5 global regions: 150 GB total cache\n(This is very achievable with modern Redis clusters)","fileName":"cache_estimation.txt","language":"plaintext"},"type":"code"},{"data":{"icon":"CheckCircle","title":"Estimation Conclusion","content":"Our estimates show the system is feasible: ~400TB storage over 10 years is manageable with distributed databases; ~60 MB/s bandwidth is modest; 30GB cache per region is achievable with Redis. The primary challenges are managing 50K+ RPS during peaks and achieving sub-50ms latency globally.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"read-write-ratio","title":"Read/Write Ratio Analysis","content":[{"data":{"content":"Understanding the read/write ratio is fundamental to URL shortener design because it profoundly impacts every architectural decision.\n\n## The Extreme Read-Heavy Nature"},"type":"text"},{"data":{"code":"Read/Write Ratio Calculation\n=============================\n\nWrites (URL creation): 100 million/day = 1,157/second avg\nReads (redirects): 1,000 million/day = 11,574/second avg\n\nRead/Write Ratio: 1000M / 100M = 10:1\n\nThis is actually conservative. In practice:\n- Popular links get clicked thousands of times\n- Many URLs created by spammers never get clicked\n- Marketing campaigns generate millions of clicks per URL\n\nReal-world ratio often: 100:1 or higher","fileName":"read_write_analysis.txt","language":"plaintext"},"type":"code"},{"data":{"content":"## Architectural Implications of Read-Heavy Workload\n\nThis extreme read-heavy ratio shapes nearly every design decision:"},"type":"text"},{"data":{"items":["**Caching is Essential** — With 10x+ more reads than writes, aggressive caching provides enormous benefits. We should cache recent/popular URLs in memory.","**Read Replicas Make Sense** — Database read replicas can horizontally scale read capacity. Slight staleness is acceptable for redirects.","**Write Performance is Secondary** — We can afford slower writes. Synchronous replication, stricter validation, and more complex write paths are acceptable if they simplify reads.","**Eventually Consistent Analytics** — Click counts can lag behind reality. Batch updates and stream processing are appropriate for analytics.","**CDN-Friendly** — Redirects for the same short code always return the same response (until updated). CDN caching can reduce origin load dramatically."],"title":{"icon":"Database","text":"Design Implications of 10:1+ Read/Write Ratio","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"left":[{"data":{"items":["Synchronous replication to multiple zones","Strong consistency for uniqueness checks","Validation and sanitization of input URLs","Write-through cache invalidation","Asynchronous indexing for analytics"],"title":{"icon":"ArrowDown","text":"Write Path (Optimize for Durability)","type":"icon","color":"secondary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Multi-layer caching (CDN → Redis → DB)","Read from nearest replica","Pre-computed redirects in memory","Minimal per-request processing","Asynchronous analytics emission"],"title":{"icon":"ArrowUp","text":"Read Path (Optimize for Latency)","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"Lightbulb","title":"Key Insight for Interviews","content":"When asked 'Why cache?' in a URL shortener interview, the answer isn't just 'for speed'—it's 'because our read/write ratio exceeds 10:1, caching reduces database load by an order of magnitude while providing sub-10ms latency for the vast majority of requests.' Numbers matter.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"system-boundaries","title":"System Boundaries and API Design","content":[{"data":{"content":"Defining clear system boundaries and APIs helps us understand exactly what the system does and how external clients interact with it.\n\n## Core API Endpoints\n\nLet's define the primary API contract:"},"type":"text"},{"data":{"code":"$69","fileName":"api_specification.ts","language":"typescript"},"type":"code"},{"data":{"content":"## HTTP Status Codes and Error Handling\n\nPrecise HTTP status codes communicate system state to clients effectively:"},"type":"text"},{"data":{"rows":[["URL created successfully","201 Created","Full ShortUrl response body"],["Redirect successful","301 or 302","Empty body, Location header"],["URL not found","404 Not Found","Error message, suggestions"],["URL expired","410 Gone","Expiration notice"],["Custom alias taken","409 Conflict","Suggestion for alternatives"],["Invalid long URL","400 Bad Request","Validation error details"],["Rate limit exceeded","429 Too Many Requests","Retry-After header"],["Authentication required","401 Unauthorized","Auth instructions"],["Server error","500/503","Error ID for support"]],"caption":"HTTP Status Codes for URL Shortener","headers":["Scenario","Status Code","Response"]},"type":"table"},{"data":{"icon":"Info","title":"301 vs 302 Redirect","content":"301 (Permanent) tells browsers to cache the redirect—future visits skip our service entirely. Good for SEO but prevents analytics. 302 (Temporary) makes browsers always hit our service first—essential for click tracking. Most URL shorteners use 302 (or 307) for clicks they want to track, 301 only when explicitly requested.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"requirements-summary","title":"Requirements Summary and Next Steps","content":[{"data":{"content":"We've completed a thorough requirements analysis for our URL shortener. Let's consolidate the key findings:\n\n## Core Operations Summary"},"type":"text"},{"data":{"rows":[["URL Shortening","100M/day (1.2K/sec)","<200ms","99.9%"],["URL Redirection","1B/day (12K/sec, 50K peak)","<50ms","99.99%"],["Analytics Query","~1M/day","<500ms","99.5%"]],"caption":"Core Operations at a Glance","headers":["Operation","Volume","Latency Target","Availability"]},"type":"table"},{"data":{"type":"ordered","items":["**Extreme Read-Heavy Workload** — 10:1+ read/write ratio means optimize aggressively for read latency.","**Short Code Uniqueness** — Must guarantee no collisions across billions of URLs.","**Sub-50ms Redirect Latency** — Requires multi-layer caching and optimized data paths.","**High Availability for Redirects** — 99.99% uptime; redirects must never block on analytics.","**Global Scalability** — Must serve users worldwide with consistent performance.","**Flexible Analytics** — Collect comprehensive data without impacting core redirect flow."],"title":{"icon":"CheckCircle","text":"Key Design Drivers","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"## What's Next\n\nWith requirements established, subsequent pages will address:\n\n1. **URL Encoding Strategies** — How to generate unique, short codes efficiently\n2. **Redirect Latency Optimization** — Caching strategies, database selection, global distribution\n3. **Analytics Collection** — Event streaming, aggregation, and query optimization\n4. **Custom Short URLs** — Handling user-provided aliases safely\n5. **Scaling Reads** — Techniques for handling billions of daily redirects"},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now have a comprehensive understanding of URL shortener requirements. The three core operations—shorten, redirect, analytics—along with detailed capacity estimates and API design provide the foundation for all subsequent architectural decisions. Next, we'll explore URL encoding strategies for generating unique short codes.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_ba474dad70c7f31c27a841684340692f","title":"URL Encoding Strategies","order":1,"content":null,"isLocked":true},{"id":"seed_24a00a96ba36f1b05e0e16177c0265e6","title":"Redirect Latency Optimization","order":2,"content":null,"isLocked":true},{"id":"seed_e75d41158a3ed636009dd52f9ea24cef","title":"Analytics Collection","order":3,"content":null,"isLocked":true},{"id":"seed_acc620ea2870d59a0adfc7777c57eae2","title":"Custom Short URLs","order":4,"content":null,"isLocked":true},{"id":"seed_4d4677cf749f4e414bed3273f4d8c180","title":"Scaling Reads","order":5,"content":null,"isLocked":true}]}}