Design a Pastebin Service: Requirements, Entities, APIs and End-to-End Architecture

Design a pastebin-style service: a user submits a block of text and receives a short link that others can open to read that text. Start from a high-level design, and cover functional requirements, non-functional requirements, core entities, API design, and a final working end-to-end solution. ### Clarifying Questions - Are users anonymous, registered, or both, and can registered users list or delete their own pastes? - Is there a maximum paste size, and is content plain text only? - Do pastes expire, and who chooses the expiration: the creator, the system, or both? - Are pastes public, unlisted (reachable only through the link), or private, and are custom short links allowed? - What traffic volume and read-to-write ratio should the design target, and are view statistics required? ### Part 1 — Functional and Non-Functional Requirements State the functional requirements you will support and the non-functional requirements that drive the design. Say explicitly which features you are deferring, and derive rough capacity estimates from the traffic assumptions you choose. ```hint Let the access pattern set priorities Consider how often a typical paste is read compared with how often one is written, and what that implies about which path must be fastest and most available. ``` #### What This Part Should Cover - Core operations (create, read by link, expiration, deletion) separated from deferred extras. - Durability, availability, read latency, and link-guessability requirements, stated as assumptions. - Storage and request-rate estimates derived from stated assumptions. ### Part 2 — Core Entities and API Design Define the core entities and their key fields, then design the external API for creating, reading, and deleting a paste. ```hint Decide where the short key comes from The short link is the primary identifier. Think about who generates it, how collisions are avoided, and whether it reveals anything such as creation order. ``` #### What This Part Should Cover - Paste metadata, paste content, and any user entity, with keys and indexes. - Request and response shapes, including error responses for missing, expired, or deleted pastes. - A short-key generation scheme and its collision and guessability properties. ### Part 3 — High-Level Design and Working Solution Present the high-level architecture, walk through the write path and the read path end to end, and evolve the design into a final solution that meets your non-functional requirements. ```hint Follow one paste through its life Trace a paste from creation, through many reads, to expiration or deletion, and identify which component would fail or saturate first at each stage. ``` #### What This Part Should Cover - Components: API service, key generation, metadata storage, content storage, and caching. - Read and write paths, including expiration and deletion. - Scaling, failure handling, abuse prevention, and monitoring. ### What a Strong Answer Covers - Requirements that visibly drive later choices, especially the read-to-write ratio and the expiration rules. - A data model and API that are consistent with the architecture. - Justified trade-offs: key generation, where content is stored, and how caching interacts with deletion and expiry. - Operational completeness: failure modes, abuse handling, and observability. ### Follow-up Questions 1. How would you support custom short links without colliding with generated keys? 2. How would you guarantee that an expired or deleted paste stops being served once it has been cached at the edge? 3. How would the design change if pastes could be edited and readers needed to see earlier versions? 4. How would you detect and throttle abuse such as automated spam or malware hosting?