System Design Interview Guide for Beginners in India 2026

Who faces system design interviews: SDE-1 (0–2 years) at Indian product companies: usually a high-level design discussion, not a full distributed system design. SDE-2 (2–5 years): full system design: expect a 40–60 minute interview on designing one significant system. SDE-3/Senior: advanced system design: multi-service, trade-offs, operational concerns.

Freshers at TCS/Infosys/Wipro: System design is rarely a dedicated round. It may appear as a question in the technical interview at the high-level ('How would you design a library management system?') but is not the deep distributed systems design that product companies test.

What interviewers are evaluating: Requirements clarification (do you ask the right questions?). Structural thinking (can you decompose a complex system into components?). Trade-off reasoning (can you justify your choices?). Scalability awareness (does your design handle 10M users?). Practicality (do you know real technologies and when to use them?). Communication (can you explain complex systems clearly?).

Step 1: Clarify requirements (2–3 minutes): Functional requirements: What does the system do? Non-functional requirements: Scale (how many users? QPS?), availability (99.9%? 99.999%?), latency (p99 < 100ms?), consistency requirements. Example: For 'Design a URL shortener': ask: How many URLs shortened per day? How many redirects per day? Should URLs expire? Custom aliases?

Step 2: Estimate scale (2 minutes): Back-of-envelope calculations. Example: 100M URLs/day shortened → ~1200 URLs/second. 10:1 read/write ratio → 12,000 redirects/second. At 500 bytes/URL, 100M/day × 365 = 18TB/year of storage.

Step 3: Define the API (2 minutes): The contract between clients and your system. POST /shorten {url: string} → {shortUrl: string}. GET /{shortCode} → 301 redirect to original URL.

Step 4: High-level design (5–10 minutes): Draw the key components: Load Balancer → Application Servers → Database. For URL shortener: client → LB → app servers → write to database (URL mapping), return short code. For redirects: client → LB → app servers → check cache (Redis) → if miss, check database → return 301.

Step 5: Deep dive (15–20 minutes): Go deeper on the interesting parts. For URL shortener: short code generation (base62 encoding of a counter, or UUID hashing), cache layer design (Redis with LRU eviction), database choice (PostgreSQL: simple relational model works fine at this scale), handling hotspot URLs (CDN + aggressive caching).

Step 6: Handle failure and scale (5 minutes): Database replication (primary-replica for reads). App server statelessness (any server can handle any request). Cache warming for newly viral short URLs. Rate limiting on the shortening API to prevent abuse.

Requirements: Users upload photos. Users follow other users. Feed shows recent photos from followed users. Support 100M daily active users.

Scale estimates: 5M photo uploads/day (~60/second). 500M feed views/day (~6,000/second reads: read-heavy system).

Core components:

Media storage: S3 for photos. Client uploads directly to S3 (presigned URL pattern): do not route large files through app servers. CDN (CloudFront) in front of S3: serves images from edge nodes closest to Indian users.

Metadata database: PostgreSQL or Cassandra. Tables: users, photos (photoid, userid, s3key, timestamp), follows (followerid, followingid). Indexes on userid, timestamp.

Feed generation: Two approaches: pull (user requests feed → query all followed users' recent photos → expensive for users following 1000 people) vs push/fan-out (when someone posts, push the photo to all followers' feed cache → expensive for celebrities with 1M followers). Hybrid: fan-out for most users, pull for celebrities.

Feed cache: Redis sorted sets: user's feed stored as a sorted set of photo IDs sorted by timestamp. App servers read from Redis, fetch photo metadata from database.

Notifications: Kafka event when a photo is uploaded → notification service → push notifications to followers (Firebase/APNs for mobile, server-sent events for web).

India-specific optimisation: Compress images aggressively for users on 4G (use WebP format, multiple resolutions via srcset). Serve CDN from Mumbai and Chennai edge nodes. Pre-warm cache for viral Reels-equivalent content.