Systemdesign Interview Questions

Functional requirements describe what the system does, such as creating an order or sending a notification. Non-functional requirements describe how well it must operate, including latency, availability, throughput, durability, security, compliance, and cost; both should be measurable before choosing an architecture.

Clarify the users, core use cases, scope, traffic shape, data size, latency targets, availability needs, consistency expectations, and constraints. State assumptions aloud, estimate the important numbers, then present a simple end-to-end design before drilling into bottlenecks and trade-offs.

Estimate users, requests per second, peak-to-average ratio, payload size, storage growth, bandwidth, and read/write ratios. Use rounded numbers and state assumptions; the purpose is to reveal pressure points such as database capacity, hot keys, queue depth, or network limits rather than to predict exact production values.

Choose SQL when relationships, transactions, constraints, and flexible querying are central. Choose a NoSQL model when access patterns are well known and horizontal scale, high write volume, or flexible schema is more important. Start from access patterns and correctness requirements, not from a technology trend.

A cache reduces latency and protects the source of truth by serving repeated reads from faster storage. Define an eviction policy, TTL, invalidation strategy, consistency expectation, capacity limit, and behavior on cache failure; cache-aside is common, but it can serve stale data and suffer cache stampedes.

A load balancer distributes requests across healthy instances, performs health checks, and can terminate TLS or route by host and path. It is not a substitute for application timeouts, graceful shutdown, connection draining, autoscaling, or an explicit strategy for stateful sessions.

Replication keeps multiple copies of data to improve read scale and availability. Sharding partitions data across nodes to increase storage and write capacity. Both add routing, rebalancing, failure-recovery, and consistency complexity, so the partition key and replication lag must be designed deliberately.

When a network partition occurs, a distributed system must trade off immediate consistency against availability for that operation. CAP does not mean a system permanently chooses only two properties, and it does not replace practical analysis of latency, replication, failure modes, and business correctness.

Use a queue to decouple producers and consumers, absorb bursts, process work asynchronously, or retry independently. Define delivery semantics, ordering, visibility timeout, dead-letter handling, retention, backpressure, and idempotent consumers; a queue improves resilience but can increase latency and operational complexity.

Choose a key such as user, token, or IP, define the limit and time window, and select a strategy such as token bucket or sliding window. For multiple application instances, keep counters in a shared low-latency store or enforce limits at the edge, and decide whether excess requests are delayed, rejected, or given a retry hint.

An idempotent operation produces the same intended business result when the same request is retried. For operations such as payments or order creation, accept a client-generated idempotency key, persist it with the outcome, enforce uniqueness, and return the original result for safe retries.

Group capabilities around business ownership, data ownership, and change boundaries rather than splitting by technical layers. A service should have a clear responsibility and a small, meaningful contract; excessive synchronous calls or shared databases often indicate boundaries that are too fine-grained.

A modular monolith is often simpler when the domain, team, and scale are still evolving. Microservices can provide independent deployment and scaling but introduce network failures, data consistency, observability, and platform costs. Choose based on team ownership and concrete scaling or isolation needs, not only expected future growth.

Remove single points of failure, run redundant instances across failure domains, use health-aware routing, automate recovery, and define graceful degradation. Availability is an end-to-end property, so include dependencies, data stores, deployments, DNS, observability, and tested failover procedures in the design.

Recovery Time Objective is the maximum acceptable time to restore service. Recovery Point Objective is the maximum acceptable amount of data loss measured in time. They determine backup frequency, replication mode, failover automation, retention, and the recovery tests a system must perform.

Instrument the four useful signals: traffic, errors, latency, and saturation, then connect metrics, structured logs, and distributed traces with correlation context. Define actionable alerts tied to user impact and test that dashboards and alerts still work during dependency failures and partial outages.

Classify data, minimize collection, encrypt in transit and at rest, manage keys separately, enforce least-privilege access, and audit sensitive operations. Redact logs and traces, protect secrets, validate authorization server-side, and design retention and deletion workflows for the relevant compliance requirements.

Generate a collision-resistant short ID, store the mapping with a uniqueness constraint, serve redirects through a cache and replicated read path, and define expiration and abuse controls. Consider read-heavy traffic, hot links, custom aliases, analytics as an asynchronous path, and what happens when the backing store is unavailable.