System Design · Beginner interview

Start by clarifying requirements — functional ones and non-functional ones like scale, read/write ratio, latency, and availability — then estimate rough numbers. Sketch a high-level design (clients, load balancer, services, database, cache), walk through the main data flows, then deepen the parts that matter and call out trade-offs and bottlenecks. The interviewer wants structured reasoning, not a memorized answer.

Latency is how long a single request takes (e.g. 50ms); throughput is how many requests the system handles per unit time (e.g. 10k requests/sec). They're related but distinct — you can improve throughput with more parallelism while latency per request stays the same, and a system can be high-throughput yet high-latency. You design for the one the product cares about, often tracking latency at percentiles like p99.

Clear, consistent resource naming and verbs (REST conventions or a well-defined RPC schema), the right status codes, pagination for large lists, versioning so you can evolve without breaking clients, and predictable error shapes. It should expose what clients need without leaking internal details, and be documented. Good APIs are stable contracts — easy to use correctly and hard to misuse.

Vertical scaling (scaling up) means a bigger machine — more CPU/RAM — which is simple but has a ceiling and a single point of failure. Horizontal scaling (scaling out) means more machines behind a load balancer, which scales further and adds redundancy but requires the system to be stateless and introduces coordination. Most large systems scale out for the stateless tiers and scale up or shard the data tier.

A load balancer distributes incoming requests across multiple server instances, so no single server is overwhelmed. It improves throughput and availability (it routes around unhealthy instances via health checks) and is what makes horizontal scaling work. It can balance by round-robin, least-connections, or other strategies, and may also terminate TLS.

A stateless server keeps no client-specific data in its own memory between requests — any instance can handle any request because shared state lives in a database, cache, or token. This lets you add or remove instances freely behind a load balancer without sticky sessions, and a crash loses no user state. Statelessness is what makes horizontal scaling and rolling deploys clean.

Use a relational SQL database when you need structured data, strong consistency, transactions, and rich queries/joins — most line-of-business apps. Use NoSQL when you need a flexible schema, very high write throughput, or horizontal scale with a known access pattern — document stores for nested data, key-value for caching/sessions, wide-column for huge scale. The choice follows your data shape, query patterns, and consistency needs, and many systems use both.

An index is a separate data structure (usually a B-tree) that maps column values to row locations, so the database can find matching rows without scanning the whole table — turning a linear scan into a logarithmic lookup. The cost is extra storage and slower writes, since every insert/update must also maintain the index. You index the columns you filter, join, or sort on.

Caching stores the result of expensive work in fast storage (in-memory like Redis, or a CDN) so repeat requests are served quickly and the backend is offloaded. You cache things that are read far more than they change — query results, rendered pages, session data, computed values. The hard parts are invalidation (keeping it fresh) and choosing a TTL, since stale cache is a classic source of bugs.

A Content Delivery Network is a network of geographically distributed edge servers that cache static content (images, JS/CSS, videos) close to users. It cuts latency by serving from a nearby location and offloads traffic from your origin. It helps any app with static assets or cacheable responses and a geographically spread user base.

Synchronous means the caller waits for a response (a normal HTTP request) — simple and immediate but the caller is blocked and coupled to the callee's availability. Asynchronous means the caller hands off work (often via a queue or event) and doesn't wait — better for slow tasks, decoupling, and absorbing spikes, at the cost of complexity and eventual results. You use async for things like sending emails, processing uploads, or fanning out events.

The browser resolves the domain via DNS to an IP, opens a connection (TCP + TLS), and sends an HTTP request, often first hitting a CDN or load balancer. The request reaches a web/app server, which may read from a cache or database and render or return data; the response (HTML/JSON, assets) comes back, with static assets frequently served from the CDN. Understanding this flow lets you reason about where latency and failures occur.