PasteBin — system design by AgileViper46

NFRs are qualitative but not measurable

Have you considered what happens when the team needs to decide whether the design actually meets the goals? 'Availability >> consistency' and 'scalability for 1M DAU' are directionally correct, but without concrete targets like read latency, write latency, or availability objectives, these NFRs do not drive clear design trade-offs.

Scalability target is not connected to the stated assumptions

Have you considered translating 1M DAU, 1 paste per user per day, 10:1 read/write, and 5MB max paste size into expected request rates and storage growth? Without tying the NFRs to those assumptions, the scale requirement stays too abstract to justify whether the system needs simple horizontal scaling or more aggressive partitioning and caching.

Consistency model is only partially defined

What happens after a paste is created or deleted if different replicas disagree temporarily? You identified strong uniqueness for URL generation, but the read path consistency expectations are still vague. It would be stronger to explicitly say whether reads can be eventually consistent after create/delete/expiry and what user-visible behavior is acceptable.

Shareable URL mapping is underspecified

Have you considered what happens when a paste is accessed via its shared URL? The requirements say pastes are shared via URLs, but the entity model does not make it clear whether pasteId itself is the public token or whether there is a separate share key/slug. Without being explicit about that relationship, the read path by URL is ambiguous.

Deletion and expiry lifecycle are not clearly modeled

Have you considered what happens when a paste is expired or deleted but still referenced by a URL? You have status and expiration on Paste, which is a good start, but the entity relationships around lifecycle are not really defined. As an interviewer, I would push on whether deleted and expired are just states on Paste or whether there is any separate tombstone/retention concept needed to make reads behave consistently.

Storage sizing stops at daily ingest

Have you considered what happens as pastes accumulate over time? The calculation gives 5TB/day, but without converting expiry assumptions into retained data volume, there is no way to size persistent storage. If many pastes live for weeks or months, the system footprint grows very quickly and could overwhelm the chosen storage layer.

Peak request math is not tied cleanly to the workload

Have you considered separating write and read peaks explicitly? From 1M writes/day and 10M reads/day, the average rates are much lower than the stated peak, but the jump to 1200 RPS is not clearly derived for total traffic versus reads only. At senior level, I would expect a clearer chain from DAU to write QPS, read QPS, and then peak multipliers so downstream sizing is easier to trust.

Server count is not justified by request cost

What happens when requests are not uniform? '20 servers' is derived from a 1 second response assumption, but that does not explain how much CPU, memory, disk, or network each server can actually handle. For a paste service with objects up to 5MB, throughput is often constrained by I/O and bandwidth more than raw request count, so server sizing needs to be tied to per-node capacity rather than latency alone.

Read and write bandwidth assume every paste is 5MB

Have you considered the impact of average object size versus max object size? Using the 5MB limit for every paste is acceptable as a worst-case upper bound, but then the rest of the architecture must be sized for that worst case. If this is meant as a realistic estimate, it likely overstates steady-state bandwidth and storage by a large margin. A senior-level answer should call out whether this is worst-case planning or expected average load.

Create flow is underspecified and may leave orphaned objects

What happens if the client calls POST /pastes, receives a pre-signed upload URL, but never uploads the content or the upload only partially succeeds? As written, the API returns PasteMetadata before the paste exists as a usable resource, which can leave dangling metadata or empty objects. You could improve this by making the flow explicit: either create a pending paste and require a finalize call after upload, or document that the object store upload itself creates the authoritative content and metadata is only committed after successful upload.

GET semantics are unclear for expired or missing pastes

Have you considered what the client sees when a paste has expired versus when the pasteId never existed? Right now only DELETE mentions 404, but the read path needs clear behavior too. Without explicit status codes, clients cannot distinguish 'not found', 'expired', and 'temporarily unavailable'. Define the response contract for GET /pastes/{pasteId}, for example 200 with metadata, 404 for unknown/expired if you want to hide existence, or a structured error body if you want clients to handle expiry differently.

Error model and retry guidance are missing

What happens when pre-signed URL generation fails, the object upload/download is rejected, or the client retries a timed-out POST /pastes request? Without status codes and a consistent error shape, clients will struggle to implement safe retries and user-facing errors. You could improve this by defining standard responses such as 400 for invalid TTL, 413 for payload too large, 429 for rate limiting, 5xx for transient failures, and an error body with code/message/retryable fields.

Read path is not fully connected end-to-end

What happens on a cache miss for GET /pastes/{id}? The diagram shows Paste service reading Redis, but there is no explicit flow from the service to Postgres or replicas for metadata lookup on misses. Without a clear fallback path, the read flow does not fully complete for uncached pastes.

Replica and Redis relationships are architecturally unclear

Have you considered what happens when Redis is cold or unavailable? The arrows show Redis reading from replicas, which is backwards from a normal application flow and makes it unclear whether replicas are actually serving application reads. This ambiguity matters because the first bottleneck at the stated read-heavy workload is likely metadata lookup, and the design should clearly show whether reads come from cache, primary DB, or replicas.

Create flow can leave dangling metadata without a clear completion state

What happens when the client gets a pre-signed upload URL, metadata is inserted, but the upload never completes or partially uploads? You mention 'stuck pastes' and cleanup, which is good, but the HLD does not show a clear state transition such as PENDING -> ACTIVE after successful upload. Without that, reads may return metadata for blobs that do not exist yet, and cleanup logic becomes the only correctness mechanism.

Expiry handling is pushed onto the synchronous read path

Have you considered what happens when many expired pastes are accessed repeatedly? The design says GET checks expiration, deletes DB state, and marks blob deletion during the request. That makes a user read trigger write-side work and background coordination, which can increase latency and create contention on hot expired keys. A periodic expiry sweeper plus lightweight read-time validation would keep the read path simpler and more available.

Primary database still looks like a single failure and scaling point

What happens when Postgres primary is down? The design includes replicas, but writes for create/delete and likely cache-miss reads still depend on the primary, and there is no failover story shown. At this scale, a single primary is a reasonable starting point, but the HLD should acknowledge promotion/failover and how the service behaves during primary loss.