Gathering Functional vs Non-Functional Requirements

When an interviewer asks you to "Design Instagram", they are deliberately giving you an impossible task. Real-world Instagram has thousands of microservices, hundreds of features (Stories, Reels, DMs, Shopping, Ads, Live Streaming, Filters, Graph Search), and thousands of engineers maintaining it.

Candidates fail this initial phase in one of two ways:

1. The Passive Trap: Asking the interviewer 20 open-ended questions like "What features do you want?" or "What database should I use?" without proposing anything.
2. The Runaway Scope Trap: Attempting to design everything at once, resulting in a shallow, cluttered diagram with zero technical depth on any single component.

Senior and Staff candidates act like Principal Architects: they immediately propose a crisp, high-value technical scope, establish concrete Service Level Objectives (SLOs), and secure the interviewer's buy-in within the first 4 to 5 minutes.

Always constrain functional scope to exactly 2 to 3 primary user journeys. Any more will dilute your 45-minute time budget; fewer will make the architecture trivial.

Every system design problem decomposes into three foundational interactions:

1. The Ingress / Ingestion Flow (Write Path): How does data enter the system? (e.g., Upload a photo, publish a tweet, book a ride, shorten a URL).
2. The Egress / Consumption Flow (Read Path): How do users access data at scale? (e.g., Generate personalized home feed, stream 4K video, query ride status, redirect short URL).
3. The Relational / Analytical Interaction: How do entities interact? (e.g., Follow/Unfollow graph, geospatial driver matching, view count aggregation).

Comparison Across Classic Interview Prompts:

Non-functional requirements (NFRs) dictate the physical constraints and architectural trade-offs of your distributed system. Never list vague buzzwords like "The system must be fast and reliable". Instead, define quantitative engineering targets:

1. Latency & Performance Targets (SLOs):

• Read Path Latency: p99 < 100 ms for API gateway responses; p95 < 50 ms for cached timeline queries.
• Write Path Latency: p99 < 500 ms for media uploads and post persistence.
• Propagation / Fan-Out Delay: Video or tweet visible to followers within 5 seconds (p99).

2. Availability vs. Consistency (CAP / PACELC):

• High Availability (AP Systems): Social feeds, video comments, and click analytics prioritize 99.99\% uptime (maximum 52.6 minutes of downtime per year). Eventual consistency is acceptable; a user seeing a tweet 2 seconds late is non-critical.
• Strong Consistency (CP / ACID Systems): Payment processing, ride fare calculation, seat reservation, and inventory management strictly require strong serializable consistency to prevent double-spending or double-booking.

3. Durability & Fault Tolerance:

• Zero Data Loss: Uploaded photos, financial transactions, and user metadata must achieve 99.999999999\% (11 9's) durability via cross-region replication (e.g., AWS S3 / Google Cloud Storage multi-AZ).

4. Scale & Workload Skew:

• Traffic Volume: 500M DAU, generating 100,000 Read QPS and 1,000 Write QPS.
• Read-to-Write Ratio: Highly read-heavy workload (100:1 read-to-write ratio), requiring aggressive multi-tier caching (Redis, CDN) rather than write-optimized LSM-tree storage.

Explicitly stating what you will not build is the single best way to protect your time budget and demonstrate senior engineering maturity. In production engineering, setting non-goals prevents scope creep; in interviews, it prevents derailment.

Standard Out-of-Scope Declarations:

• User Authentication & Signup: State that JWT token validation is handled upstream at the API Gateway.
• Payment Processing & Invoicing: Outsource to Stripe/PCI-compliant external gateways unless the question is explicitly "Design Stripe".
• Direct Messaging & Chat: DMs require WebSockets, long polling, and Cassandra inbox tables—completely distinct from public feed generation.
• Recommendation ML Algorithms: Acknowledge machine learning scoring as an external black-box model ranking service, focusing on the distributed data pipeline that feeds it.
• Analytics & Billing Dashboards: Treat offline MapReduce/Spark data warehousing as a separate asynchronous pipeline.

Use these exact conversational frameworks to take control of the scoping phase:

The 60-Second Opening Scoping Pitch: "Thank you for the prompt. To make sure we design a robust architecture and dive deep into the hardest distributed challenges, I would like to propose the following scope:

For Functional Requirements, I suggest we focus on three core user flows:

1. Users can upload photos with captions.
2. Users can follow other users.
3. Users can view a chronological and algorithmic home feed of followed posts.

For Non-Functional Requirements, I am targeting:

• High availability (99.99\%) with eventual consistency on the feed.
• Low read latency (p99 < 150 ms).
• Scale of 500M DAU with a 100:1 read-to-write ratio.

And to ensure we have adequate time for feed fan-out and sharding, I propose treating Direct Messaging, Stories, and Image Editing as Out of Scope for today. Does this scope align with what you'd like to evaluate?"