System Design Interview Questions

Scalability is the ability to handle more load (users, requests, data) by adding resources without redesigning core architecture. Often discussed as handling 10x traffic with acceptable latency and cost.

A student project API might serve 10 RPS; production might need 10,000 RPS via horizontal scaling and caching.

• Difference between scalability and performance?
• What metrics define ‘handles load’?
• Vertical vs horizontal?

• Equating scalability only with cloud spend
• Ignoring database bottlenecks
• Designing for Google scale on day one

Frame your capstone: what breaks first if 1000 users hit it at once?

Vertical scaling adds power to one machine (CPU/RAM). Horizontal scaling adds more machines. Vertical has limits and single point of failure; horizontal needs load balancing and often stateless app servers.

Upgrade one Node server from 2GB to 8GB RAM (vertical). Run four identical Node instances behind a load balancer (horizontal).

• When is vertical scaling enough?
• Stateful vs stateless with horizontal?
• Database scaling differences?

• Only mentioning auto-scaling without app changes
• Forgetting session stickiness issues
• Assuming horizontal is always cheaper

Mention which approach your deployed MERN app would use first.

A load balancer distributes incoming requests across multiple backend servers using algorithms (round-robin, least connections). Improves availability, throughput, and enables rolling deploys.

Users → ALB → [API-1, API-2, API-3]. Health checks remove unhealthy instances.

• Layer 4 vs Layer 7 LB?
• Sticky sessions?
• What is health check?

• Single server with no failover plan
• Not considering WebSocket stickiness
• Ignoring SSL termination at LB

Sketch LB in front of two Express instances in a whiteboard answer.

Caching stores frequently read data closer to the consumer to cut latency and database load. Layers: browser cache, CDN, reverse proxy, application memory (Redis), database query cache.

Cache user profile in Redis with 5-minute TTL; serve feed from cache on cache hit.

• Cache invalidation strategies?
• TTL vs write-through?
• Thundering herd?

• Caching everything with no invalidation
• Stale data breaking auth
• Using cache as source of truth

Add Redis caching to a slow GET endpoint and cite hit rate in interviews.

A Content Delivery Network caches static assets (JS, CSS, images, video) at edge locations near users. Reduces origin load and latency. Great for global audiences and large media.

Host React build on S3 + CloudFront; images served from nearest PoP.

• CDN for dynamic HTML?
• Cache busting with hashes?
• Invalidation?

• Putting API responses on CDN without thought
• Forgetting HTTPS at edge
• Not versioning asset filenames

Deploy portfolio on Vercel/Netlify and explain their CDN briefly.

Read-heavy: replicas, caching, read replicas, materialized views. Write-heavy: sharding, partitioning, queue-based writes, choosing DB suited to access pattern. Often start with one primary DB and optimize reads first.

Instagram-like read: replicas + cache for feeds. Write-heavy logging: append-only store or partitioned tables.

• What is replication lag?
• When to shard?
• SQL vs NoSQL scaling?

• Sharding on day one
• Ignoring connection pool limits
• Master-replica without handling stale reads

Describe one table in your project that would need indexes first.

In a network partition, distributed systems trade off Consistency (all nodes see same data) vs Availability (every request gets a response). Partition tolerance is assumed in distributed systems. Pick CP or AP based on product needs.

Bank balance updates favor consistency; social like counts might tolerate eventual consistency.

• What is eventual consistency?
• Examples of CP systems?
• Does CAP apply to single DB?

• Memorizing without examples
• Claiming you can have all three during partition
• Confusing CAP with ACID

Say whether your chat ‘last seen’ must be strongly consistent or not.

Use nouns for resources (/users, /posts), HTTP verbs correctly, meaningful status codes, pagination, versioning (/v1), consistent error shape, and idempotent updates where needed. Document with OpenAPI.

GET /v1/posts?page=2&limit=20; POST /v1/posts; PATCH /v1/posts/:id

• REST vs GraphQL tradeoffs?
• HATEOAS needed?
• Nested routes limits?

• Verbs in URLs like /getUsers
• 200 OK with error body
• No pagination on list endpoints

Refactor your Express routes to resource-oriented URLs before interviews.

Rate limiting caps requests per client/IP/API key in a time window to prevent abuse and protect resources. Implement with token bucket or sliding window in Redis; return 429 with Retry-After.

100 requests/minute per API key; increment counter in Redis with TTL.

• Difference from throttling?
• Distributed rate limits?
• User-facing UX?

• No limits on login endpoint
• Rate limit per server only without shared store
• Blocking legit traffic behind NAT

Propose rate limits for login vs public read endpoints in your API.

WebSockets give persistent bidirectional connection — good for chat, live scores, collaborative edits. HTTP polling/simple SSE work for lower complexity or one-way server push.

Chat app: WebSocket channel per room. Notification badge: SSE or long poll might suffice.

• WebSocket scaling?
• Heartbeat/reconnect?
• SSE vs WebSocket?

• WebSockets for every CRUD page
• Ignoring load balancer sticky sessions
• No auth on socket handshake

If you built chat, explain message flow client → server → other clients.

Publishers send messages to topics; subscribers receive without knowing publishers. Enables async processing, fan-out notifications, and microservice communication via brokers (Redis Pub/Sub, SNS/SQS, Kafka at scale).

Order placed event → email service + inventory service subscribe independently.

• Pub/sub vs message queue?
• At-least-once delivery?
• Ordering guarantees?

• Using pub/sub without durability needs
• Tight coupling disguised as events
• No idempotent consumers

Describe emailing users after signup using a queue instead of blocking HTTP.

Monolith: one deployable codebase — simpler for small teams and MVPs. Microservices: split by bounded context — independent deploys, more ops complexity. Start monolith; extract services when clear pain (scale, team boundaries).

Student e-commerce MVP as monolith; split payments service only when compliance/isolation needed.

• How do services communicate?
• Distributed tracing?
• Data ownership per service?

• Microservices for 3-person internship project
• Shared database across all services
• Ignoring network latency between services

Defend keeping your final-year project a monolith with a migration path.

Stateless servers don’t store user session data in memory between requests. Any instance can handle any request — simplifies horizontal scaling and rolling updates. Session state moves to DB, Redis, or JWT.

Express app stores sessions in Redis, not in-process Map.

• What about WebSocket state?
• Sticky sessions downside?
• JWT pros/cons?

• In-memory sessions on scaled fleet
• Assuming stateless means no auth
• Huge JWT payloads

Note if your app uses express-session in memory and how you’d fix it.

Options: server-side session ID in HTTP-only secure cookie pointing to Redis/DB; or stateless JWT (access + refresh). Rotate refresh tokens, set expiry, invalidate on logout, use HTTPS, CSRF protection for cookies.

Login → set session cookie → middleware loads user from Redis on each request.

• JWT vs session cookies?
• SameSite cookie attribute?
• OAuth role?

• localStorage for session JWT with XSS risk
• No refresh/expiry strategy
• Session fixation ignored

Walk through login → authenticated request in your Express middleware.

Don’t store files on app server disk at scale. Use object storage (S3) with metadata in DB. Generate pre-signed URLs for direct upload/download; virus scan async; CDN for public assets.

Client uploads to S3 via presigned PUT; DB stores key, mime, owner_id.

• Multipart upload?
• Image resizing pipeline?
• Access control?

• Storing blobs in SQL rows
• Public bucket for private files
• No size/type validation

If your app has avatars, describe S3 + DB metadata pattern.

Components: event producer, notification service, preference store, channel workers (email, push, in-app), template engine, delivery queue, read/unread store. Fan-out via queue; respect user opt-in.

New comment → event → queue → in-app row + optional email if enabled.

• Push notification providers?
• Idempotent delivery?
• Batching digests?

• Sending email synchronously in request path
• No user preferences
• Duplicate notifications on retry

Map notifications for ‘friend request’ across DB, queue, and UI badge.

Simple: SQL LIKE or full-text indexes for small data. Scale: dedicated search engine (Elasticsearch/OpenSearch) fed by change data capture or async indexing. Support ranking, facets, typo tolerance.

Products table in Postgres for MVP; sync to Elasticsearch for autocomplete at scale.

• Inverted index idea?
• Search vs filter?
• Reindex strategy?

• Elasticsearch for 500 rows
• Searching only on client for huge catalogs
• No pagination of results

Propose SQL full-text for your project search before jumping to Elastic.

Offset/limit is simple but slow on large offsets. Cursor/keyset pagination uses last seen id/timestamp for stable, efficient next pages. Return next_cursor and consistent sort order.

GET /posts?cursor=eyJpZCI6MTIzfQ&limit=20

• When is offset ok?
• Deep paging problems?
• Total count needed?

• No limit allowing huge responses
• Unstable sort breaking pages
• Exposing internal DB ids without thought

Add cursor pagination to a long list endpoint in your API design answer.

An operation is idempotent if repeating it has the same effect as doing it once. Critical for retries after network failures. Use idempotency keys on POST, or design PUT/DELETE idempotently.

Client sends Idempotency-Key: uuid on payment POST; server stores result for key.

• Which HTTP methods are idempotent?
• Duplicate message handling?
• Database upsert?

• Double-charging on retry
• POST that always creates new row
• No dedup on webhooks

Explain idempotent webhook handler for Stripe-like events.

API gateway is a front door routing clients to backend services, often handling auth, rate limiting, SSL, request routing, and aggregation. Examples: Kong, AWS API Gateway, NGINX.

Mobile app → API Gateway → users service / orders service

• Gateway vs load balancer?
• BFF pattern?
• GraphQL at gateway?

• God gateway with all business logic
• Skipping auth at gateway and duplicating
• Single point of failure without HA

Place gateway in diagram between React app and multiple microservices.

Organize by feature or domain, shared UI kit for primitives, container/presentational split or hooks for logic, lazy routes for code splitting, clear props/contracts, Storybook for reusable components, avoid prop drilling with context sparingly.

features/feed/FeedList.tsx, components/ui/Button.tsx, hooks/useFeed.ts

• Atomic design?
• When to extract a hook?
• Barrel files pitfalls?

• One giant App.tsx
• Duplicated fetch logic in every page
• No design tokens for spacing/color

Describe folder structure of your React portfolio like a mini design doc.

Local component state for UI-only; Context for theme/auth light usage; server state libraries (React Query) for API cache; Redux/Zustand for complex client-global state. Prefer colocation and server cache over global soup.

React Query caches posts; Zustand holds UI filters; form state stays in component.

• When is Redux still justified?
• Stale closure issues?
• SSR hydration?

• Global store for every fetch
• Duplicating server data in Redux
• No loading/error states

Justify your state choices in your React project in one minute.

User submits credentials → server validates hash (bcrypt) → issue session cookie or JWT pair → client sends cookie/Authorization header → middleware verifies → attach user to request → authorize by role/resource.

POST /login → HTTP-only cookie → GET /me protected route.

• OAuth social login?
• Password reset flow?
• RBAC vs ABAC?

• Plaintext passwords
• JWT in localStorage
• No HTTPS mention

Narrate auth middleware chain in your Express app line by line.

Start from entities and relationships, access patterns, and normalization tradeoffs. Define primary keys, indexes for queries, avoid N+1 with joins or batching, use migrations, consider soft deletes and audit fields.

Users 1—N Posts; index posts(user_id, created_at) for profile feed query.

• Normalization vs denormalization?
• Many-to-many join tables?
• UUID vs int ids?

• Schema with no indexes on foreign keys
• Storing arrays in strings
• No created_at for sorting

Draw ER diagram for your project’s main three tables in interviews.

MVP: users follow users; posts table; home feed query joins following list + posts ordered by time with pagination. Scale: precompute fan-out on write (push) or pull model with caching; media on CDN; like counts with async counters.

Pull model: on open app, fetch ids user follows, query recent posts WHERE user_id IN (…) LIMIT 20.

• Fan-out on write vs read?
• Celebrity user problem?
• Ranking beyond chronological?

• Feed from single SQL with no index
• Loading all images at once
• Ignoring cache for hot users

Compare your Twitter/feed clone approach to push vs pull in one slide.

Clients connect via WebSocket to chat service; messages persisted in DB (conversation_id, sender, body, ts); presence optional in Redis; history via REST pagination; delivery acks; auth on connection; scale with room sharding or dedicated chat nodes.

WS message → validate membership → insert message → broadcast to room subscribers.

• Message ordering?
• Offline delivery?
• End-to-end encryption scope?

• No persistence — reload loses chat
• Broadcast to all users globally
• No backpressure on spam

If you have a chat demo, walk message path from send click to peer UI.

Generate short code (base62) mapping to long URL in DB; 301/302 redirect on GET /:code; handle collisions; optional analytics click table; cache hot codes in Redis; rate limit creation.

POST {url} → store → return short link; GET /abc123 → lookup → redirect.

• Custom aliases?
• Expiration?
• How many URLs fit in 7 chars?

• Only hash without collision check
• Storing only in memory
• Open redirect security hole

Relate base62 codes to primary keys vs random strings in interview.

Use timeouts, retries with exponential backoff and jitter, circuit breakers, idempotent handlers, dead-letter queues for poison messages, and health checks. Log correlation ids across services.

HTTP client retries 3 times on 503; then surfaces error; webhook worker DLQ after 5 fails.

• Exactly-once myth?
• Saga pattern basics?
• Graceful degradation?

• Infinite retries hammering DB
• No timeout on external APIs
• Retry without idempotency

Add timeout + retry to a fetch to third-party API in your design narrative.

Synchronous: client waits until work completes in same request (good for quick reads/writes). Asynchronous: API enqueues job, returns 202, client polls or gets webhook when done — for emails, PDF generation, heavy transforms.

POST /export → job id → worker builds CSV → notify user.

• When is 202 Accepted used?
• Webhooks vs polling?
• Backpressure?

• Blocking HTTP for 2-minute report
• No job status endpoint
• Losing jobs on server restart without queue

Move image resize off request path in your upload feature story.

HTTPS everywhere, hash passwords, validate/sanitize input, authn + authz on every route, secrets in env/vault, least privilege DB users, rate limits, CORS configured intentionally, audit logs for sensitive actions.

Admin routes check role; SQL via parameterized queries; CSP headers on frontend.

• OWASP top 10?
• Secrets in git?
• SSRF on webhooks?

• Security only as afterthought
• CORS * with credentials
• Logging passwords

Close every design answer with 2–3 security bullets — interviewers notice.

Structured logs (JSON), request ids, error tracking (Sentry), basic metrics (latency, error rate, RPS), uptime checks, alerts on 5xx spikes. Don’t log PII.

Middleware logs method, path, duration; Sentry captures stack traces.

• Distributed tracing?
• Log aggregation?
• SLI/SLO basics?

• console.log only in production
• No alerting
• Logging full JWT tokens

Mention one metric you’d watch after deploying your capstone.

Indexes speed up reads on filtered/sorted columns but slow writes and use storage. Design indexes around query patterns (WHERE, JOIN, ORDER BY). Explain plans for slow queries.

INDEX on posts(created_at DESC) for recent posts feed.

• Composite indexes?
• Covering index?
• When indexes hurt?

• Index every column
• No index on foreign keys
• Ignoring N+1 query problem

Name one slow query you’d EXPLAIN ANALYZE in your project DB.