System Design for Freshers: 10 Concepts Every Interviewer Expects You to Know

Freshers often skip system design preparation entirely because "it's for experienced engineers." This is a mistake.

At Indian product companies (Swiggy, Zomato, CRED, Razorpay, Freshworks) and at most MNCs hiring freshers, you will be asked basic system design questions. Not "design Twitter" — but things like: "How would you design a URL shortener?" or "What happens when you type a URL in the browser?"

This guide covers exactly what you need to know. Nothing more.

---

1. Client-Server Architecture

What it is: The foundational model of the web. A client (browser, mobile app) sends a request. A server processes it and sends a response.

HTTP methods:

• GET — retrieve data (no side effects)
• POST — create new data
• PUT — update/replace data
• DELETE — remove data
• PATCH — partially update data

Status codes you must know:

• 200 OK — success
• 201 Created — resource created
• 400 Bad Request — invalid input from client
• 401 Unauthorized — not authenticated
• 403 Forbidden — authenticated but not allowed
• 404 Not Found — resource doesn't exist
• 500 Internal Server Error — something broke on the server

Why it matters in interviews: When designing any system, start by describing the API (what requests/responses look like). This shows structured thinking.

---

2. Databases: SQL vs NoSQL

This is the most common decision you'll be asked to justify.

SQL (Relational)

Examples: PostgreSQL, MySQL, SQLite

• Data is stored in tables with fixed schemas
• Enforces ACID properties (Atomicity, Consistency, Isolation, Durability)
• Excellent for: financial data, user profiles, anything with complex relationships and joins
• Use when: data structure is well-defined, consistency is critical

NoSQL

Examples: MongoDB (documents), Redis (key-value), Cassandra (wide-column)

• Flexible schema — each document can have different fields
• Scales horizontally more easily
• Trades consistency for availability in some configurations
• Use when: data is unstructured, write volume is very high, simple lookups dominate

The answer most interviewers want:

"I'd use PostgreSQL here because the data has clear relationships and we need ACID guarantees for [this use case]. If we later need to scale writes beyond what a single Postgres instance can handle, we'd consider a NoSQL solution for [specific data like logs or sessions]."

---

3. Caching

What it is: Storing the result of an expensive operation so future requests return it without recomputing.

The problem it solves: A database query that takes 50ms repeated 10,000 times per second = 500 seconds of DB time per second. Cache it → 1 DB query, 9,999 cache hits at ~0.1ms each.

Where to cache

Browser cache: Static assets (CSS, JS, images) are cached locally. Headers like Cache-Control tell the browser how long to keep them.

CDN (Content Delivery Network): Caches static content at servers physically close to users. A user in Chennai hits a CDN node in Chennai, not your server in Mumbai.

Application cache (Redis): Key-value store in memory. Typical uses:

• Session data
• Rate limiting counters
• Expensive DB query results
• User profile data that doesn't change often

User requests profile for user_id=123

1. Check Redis: GET user:123
2. Cache HIT → return cached data (0.1ms)
   Cache MISS → query Postgres (50ms), store in Redis with 5min TTL

Cache invalidation is the hard problem: when data changes in the DB, the cached version is stale. Common strategy: write-through (update cache on every write) or set a short TTL (time-to-live).

---

4. Load Balancing

What it is: Distributing incoming requests across multiple servers so no single server is overwhelmed.

Why it's needed: One server can handle ~1,000-10,000 requests/second. Popular apps get millions. Solution: run 10-100 servers and split the traffic.

Common algorithms:

• Round robin: Request 1 → Server A, Request 2 → Server B, Request 3 → Server C, repeat
• Least connections: Send to whichever server has fewest active connections
• Consistent hashing: Used when requests for the same key must go to the same server (e.g., chat sessions)

What to say in an interview:

"I'd put a load balancer in front of the application servers to distribute traffic. For stateless services, round robin works well. If sessions need to be sticky, I'd use consistent hashing."

---

5. Horizontal vs Vertical Scaling

Vertical scaling (scale up): Make the one machine bigger — more CPU, more RAM, faster disk.

• Simple — no code changes
• Has a hard limit (you can't buy a machine with infinite RAM)
• Single point of failure

Horizontal scaling (scale out): Add more machines.

• No hard limit — keep adding servers
• More complex — requires stateless services, load balancers
• No single point of failure (if designed correctly)

The rule: For most modern web applications, horizontal scaling is preferred. Design your services to be stateless (no session stored in memory on the server) so any server can handle any request.

---

6. APIs and REST

REST (Representational State Transfer) is the standard pattern for web APIs.

Key constraints:

1. Stateless: Each request contains all information needed. Server doesn't remember previous requests.
2. Resource-based: URLs represent resources (nouns), not actions (verbs)
3. Use HTTP methods for actions (GET/POST/PUT/DELETE)

Good REST API design:

GET    /users/123          → get user 123
POST   /users              → create a new user
PUT    /users/123          → update user 123
DELETE /users/123          → delete user 123
GET    /users/123/orders   → get orders for user 123
POST   /users/123/orders   → create an order for user 123

What's wrong with this:

GET /getUser?id=123        ❌ verb in URL
POST /deleteUser/123       ❌ wrong HTTP method for delete
GET /user_data             ❌ inconsistent naming

---

7. Message Queues

What they are: A system for passing messages between services asynchronously. Producer puts a message in the queue; Consumer picks it up when ready.

The problem they solve: Imagine a user uploads a video. Processing the video takes 10 minutes. You don't want the user to wait 10 minutes for the HTTP response. Solution:

1. User uploads → server saves file, puts a process_video job in the queue → returns 202 Accepted immediately
2. Video processing service picks up the job from the queue → processes video in background
3. User gets notified when done

Examples: RabbitMQ, Apache Kafka, AWS SQS, Redis queues

When to mention them in interviews: Any time there's a background task (sending emails, processing images/videos, generating reports, sending notifications).

---

8. CDN (Content Delivery Network)

What it is: A network of servers distributed geographically. Static assets (images, CSS, JS, videos) are cached on CDN servers close to users.

The problem it solves: Network latency is proportional to physical distance. Mumbai to Chennai: ~5ms. Mumbai to São Paulo: ~200ms. Serve static assets from a CDN node in the user's region.

What gets CDN-cached: Images, videos, fonts, JavaScript bundles, CSS, HTML for static pages.

What doesn't: Dynamic, user-specific content (dashboards, personalised feeds, real-time data).

Examples: Cloudflare, AWS CloudFront, Akamai, Fastly.

---

9. Sharding and Replication

These are advanced database techniques, but freshers should know the concepts.

Replication: Copy your database to multiple servers.

• Primary: handles all writes
• Replicas: handle reads, stay in sync with primary
• Increases read throughput and provides failover

Sharding (partitioning): Split data across multiple databases.

• Users 1-10M → DB1, Users 10M-20M → DB2
• Each shard handles a fraction of the total data
• Required when a single DB machine can't hold all data or handle all writes

In a fresher interview: You'll rarely be asked to design a sharded system. But knowing the term and basic idea — "if one database can't handle the load, split data across multiple databases by a shard key like user_id" — is enough.

---

10. How to Structure a System Design Answer

Most freshers fail system design not because they lack knowledge but because they don't have structure. Use this framework:

The 5-minute structure

1. Clarify requirements (1-2 min)

• What are the core features? (Don't try to build everything)
• Scale: how many users, requests per second?
• Any specific constraints?

2. Estimate scale (1 min)

• "Let's say 1 million users, 10,000 requests/second at peak"
• "Each user generates ~1KB of data per day → ~1GB/day storage"

3. Design the API (1-2 min)

• What endpoints are needed?
• Request/response format?

4. High-level architecture (5-10 min)

• Draw: Client → Load Balancer → App Servers → Database
• Add cache, queue, CDN as needed
• Justify each component with one sentence

5. Deep dive on one component (if time allows)

• Pick the hardest part (usually the database or the hot path)

---

Practice Problem: Design a URL Shortener

Apply the above framework to this classic problem:

Requirements: User enters a long URL → gets a short URL (like scs.co/abc123) → anyone visiting the short URL is redirected to the long URL.

Components needed:

• API: POST /shorten → returns short URL, GET /{shortCode} → redirect
• Database: store mapping of short_code → long_url
• Cache (Redis): cache popular short codes to avoid DB hits on every redirect
• Why no queue? Shortening is fast, redirects need to be instant

The key technical question: How do you generate unique 6-character codes?

• Hash the long URL (MD5/SHA256), take first 6 chars
• Use a counter and encode in base62 (a-z, A-Z, 0-9)
• Second option avoids hash collisions

This single problem touches on APIs, databases, caching, and algorithm design — everything in this article.

Next step: Use the Mock Interview tool and select "System Design" as the role. Practice articulating your thinking out loud — that's the skill system design interviews actually test.