Skip to main content
Always remember: the first five minutes of a design interview are not about drawing. Interviewers want to hear how you think, scope problems, and make trade-offs — not just see a diagram. When asked to design something like a photo-sharing app, resist the impulse to start sketching immediately. Instead, spend the first few minutes clarifying scope and constraints. Those answers become the pillars that justify every component you add later. Key clarifying questions to ask up front:
  • How many users are we designing for? (expected scale)
  • Is the workload read-heavy or write-heavy?
  • What data can we never lose? (durability constraints)
  • How fast must the system feel? (latency, perceived performance)
  • What consistency guarantees do we need?
  • What are the storage and retention requirements for photos?
  • Are there special features (sharing, comments, stories, editing)?
  • Are third-party integrations required (CDNs, authentication providers)?
  • What are the failure and recovery expectations (RTO/RPO)?
  • Any compliance, privacy, or moderation requirements?
The image shows a simple stick figure diagram with an "interviewer" and "you," with options to "start drawing" or "ask questions first." The figures are seated, facing each other, with corresponding labels above them.
Why these questions matter — quick mapping How to convert answers into architecture decisions
  • Define the scope and prioritize the system’s non-functional requirements (scale, latency, durability).
  • Map each requirement to a concrete component or pattern:
    • Read-heavy: introduce caches (in-memory, CDN) and read replicas.
    • Strong delete consistency: ensure synchronous operations or employ distributed transactions for deletes.
    • Large media storage and retention: use object storage (S3-style) with lifecycle rules.
    • Low latency perceived by users: place static media behind a CDN and use edge caching.
  • For each component you propose, explicitly state which interview requirement it satisfies and what trade-offs it introduces.
Example decision patterns
  • Reads dominate → Cache layer (reduce DB load, faster responses). Use TTLs and invalidation strategies tailored to freshness requirements.
  • Strong consistency for deletes → enforce synchronous writes to the canonical datastore or implement a delete-confirmation workflow.
  • Large photo storage with infrequent access → object storage + lifecycle tiering (hot to cold), and serve through CDN for global performance.
  • High availability and low RTO → multi-region replication, automated failover, and frequent backups.
The image depicts a simplified diagram of a caching system, emphasizing that "a cache—because reads dominate," with icons representing users, read/write operations, data loss prevention, and speed. Two stick figures are labeled as "interviewer" and "you."
Practical interview tips
  • Verbalize assumptions and ask for confirmation. Example: “I’ll assume 10M monthly active users unless you say otherwise.”
  • Tie every architecture decision back to a requirement. This shows intentional design rather than guesswork.
  • Sketch a high-level diagram only after you’ve solidified the main constraints.
  • Discuss trade-offs and alternative approaches briefly (cost, complexity, latency).
  • If time permits, call out edge cases (data retention, abuse detection, rate limiting).
References and further reading
Begin every design discussion by eliciting requirements. Use those answers as justification for each major architectural choice you make during the rest of the design.

Watch Video