System Design MCQ

Explanation

System design focuses on high-level structure — how components interact, scale, and meet requirements like performance, reliability, and availability — before or alongside implementation.

Explanation

Functional requirements specify features and behaviors (e.g., "users can log in"), while non-functional requirements specify system qualities (e.g., "must handle 10,000 requests/sec").

Explanation

Scalability describes how well a system can grow to handle more load, either by adding more powerful machines (vertical) or more machines (horizontal).

Explanation

Vertical scaling ("scale up") increases a single server's capacity, while horizontal scaling ("scale out") distributes load across multiple servers, often offering better fault tolerance.

Explanation

A load balancer sits in front of multiple servers and distributes incoming requests among them, preventing any single server from becoming a bottleneck or single point of failure.

Explanation

Caching stores copies of data (e.g., in memory) closer to where it's needed, reducing repeated expensive computations or database queries and improving response times.

Explanation

Indexes (often B-trees) allow the database to find rows matching a query without scanning the entire table, significantly speeding up reads at some cost to write performance.

Explanation

SQL databases (like PostgreSQL, MySQL) enforce schemas and relationships with ACID guarantees, while NoSQL databases (like MongoDB, Cassandra, Redis) trade some consistency or structure for flexibility and horizontal scalability.

Explanation

An API (Application Programming Interface) defines how different software components interact, specifying requests, responses, and data formats, enabling modular and decoupled systems.

Explanation

Latency measures delay — how long it takes for an operation (like a network request) to complete — and is a key performance metric users directly experience.

Explanation

Throughput is often measured in requests per second (RPS) or transactions per second (TPS), reflecting a system's overall processing capacity.

Explanation

CDNs distribute copies of static content (images, scripts, videos) across edge servers worldwide, so users are served from a nearby location, reducing latency and origin server load.

Explanation

Availability is often expressed as a percentage of uptime (e.g., "99.9% availability"), indicating how reliably a system is accessible to users.

Explanation

Identifying and eliminating SPOFs (e.g., via redundancy, replication, failover) is a key goal in designing reliable systems, since a single failure shouldn't bring down the whole system.

Explanation

Redundant components (extra servers, replicated data) provide failover options, increasing a system's overall reliability and availability when individual parts fail.

Explanation

A reverse proxy receives client requests on behalf of backend servers, providing benefits like load balancing, caching, compression, and centralized SSL handling.

Explanation

Replication maintains copies of data across multiple servers (e.g., primary-replica setups), enabling read scaling, failover, and protection against data loss.

Explanation

Synchronous calls (like typical HTTP requests) block until a response arrives, while asynchronous communication (like message queues) lets the caller proceed and handle the result later.

Explanation

Message queues decouple the sender and receiver in time, allowing producers to send messages without waiting for consumers to process them immediately, improving resilience and scalability.

Explanation

Fault-tolerant systems are designed with redundancy and failure-handling mechanisms so that individual component failures do not cause overall system outages.

Explanation

Health check endpoints (e.g., /health) report whether a service and its dependencies are functioning, enabling automated systems to route traffic away from unhealthy instances.

Explanation

Monolithic applications package all functionality into one deployable unit, which can be simpler to develop initially but harder to scale or update independently as it grows.

Explanation

Microservices break an application into smaller, independently deployable services, each focused on a specific capability, communicating via APIs or messaging.

Explanation

Rate limiting protects services from being overwhelmed by too many requests (whether accidental or malicious), ensuring fair usage and system stability.

Explanation

DNS acts like a phonebook for the internet, mapping domain names to IP addresses so browsers know which server to connect to.

Explanation

HTTPS encrypts the communication channel using TLS, protecting data from eavesdropping and tampering, while HTTP transmits data in plaintext.

Explanation

Sharding divides data across multiple database instances (shards) based on a partition key, allowing a system to scale beyond what a single database server can handle.

Explanation

Queues buffer work between producers and consumers, allowing each to operate at their own pace and absorbing spikes in load without overwhelming downstream systems.

Explanation

Stateless APIs (a core REST principle) treat each request independently, simplifying scaling since any server instance can handle any request without needing shared session state.

Explanation

Vertical partitioning separates columns (e.g., frequently accessed vs. rarely accessed) into different tables, which can improve performance for queries that only need a subset of columns.

Explanation

Logs provide a historical record of what a system did, which is essential for diagnosing issues, understanding usage patterns, and auditing security events.

Explanation

Monitoring tools track key metrics and alert teams to anomalies (e.g., high error rates or latency spikes), enabling proactive issue detection before users are significantly impacted.

Explanation

SLAs define measurable targets (like "99.9% uptime") and often consequences for not meeting them, setting expectations between providers and customers.

Explanation

Object storage services provide scalable, durable storage for files and blobs (images, videos, backups), accessed via simple APIs, separate from compute or relational databases.

Explanation

Understanding read/write ratios guides design choices — read-heavy systems benefit from caching and read replicas, while write-heavy systems may need optimized storage engines, batching, or sharding.

Explanation

Polling involves repeated requests to check for changes, which is simple to implement but can be inefficient compared to push-based mechanisms like WebSockets for real-time updates.

Explanation

WebSockets keep a connection open, allowing the server to push data to the client (and vice versa) without repeated request/response cycles, ideal for chat apps or live updates.

Explanation

Capacity estimation (users, requests/sec, storage growth) helps justify design decisions like the need for caching, sharding, or specific database choices.

Explanation

Load testing helps identify bottlenecks and ensures a system can handle anticipated traffic before real users are affected, informing capacity planning decisions.

Explanation

Session-based auth stores state server-side (e.g., in Redis), while token-based auth (JWT) embeds claims in a signed token the client holds, enabling stateless verification across servers.

Explanation

During a network partition, a system must choose between staying consistent (rejecting some requests) or remaining available (potentially serving stale data), while always being partition tolerant in distributed systems.

Explanation

Strong consistency requires synchronous coordination (often at a latency cost), while eventually consistent systems prioritize availability/performance and allow temporary divergence between replicas.

Explanation

While sharding enables horizontal scaling of storage and write throughput, cross-shard joins, transactions, and rebalancing data when adding/removing shards become significantly more complex.

Explanation

Read replicas duplicate the entire dataset to handle more read traffic, while sharding partitions the dataset itself, allowing the system to scale storage and write capacity beyond a single node.

Explanation

When a cache reaches capacity, an eviction policy like LRU, LFU (Least Frequently Used), or FIFO decides which entries to remove to make room for new data.

Explanation

Keeping caches in sync with the source of truth is notoriously tricky — stale data can be served if invalidation is missed, while overly aggressive invalidation reduces caching benefits.

Explanation

Write-through ensures consistency at the cost of higher write latency; write-back improves write performance but risks data loss if the cache fails before the data is persisted.

Explanation

Message brokers enable services to communicate without direct, synchronous coupling, improving resilience — if a consumer is down, messages can wait in the broker until it recovers.

Explanation

Network failures may cause clients to retry requests; idempotent endpoints (e.g., using a unique request ID or PUT semantics) ensure retries don't create duplicate orders, charges, etc.

Explanation

Horizontal partitioning (sharding by row) distributes both storage and query load across many servers, which is typically more effective for scaling very large datasets than vertical (column-based) partitioning alone.

Explanation

Consistent hashing maps keys and nodes onto a hash ring such that adding/removing a node only affects a small fraction of keys, minimizing reshuffling compared to simple modulo hashing.

Explanation

An API Gateway centralizes common functionality (auth, rate limiting, routing, monitoring) so individual microservices don't each need to implement it, simplifying client interactions.

Explanation

In dynamic environments (containers, auto-scaling), service instances' IPs change frequently; service discovery (e.g., via a registry like Consul or Kubernetes DNS) lets services find each other automatically.

Explanation

Circuit breakers monitor failure rates to a dependency; after exceeding a threshold, they "open" and fail fast for a period, preventing resource exhaustion from waiting on a failing dependency, then periodically test recovery.

Explanation

Token bucket and leaky bucket algorithms manage request rates by allowing tokens to accumulate up to a limit (token bucket) or processing requests at a fixed rate while queuing excess (leaky bucket).

Explanation

Pessimistic locking avoids conflicts by blocking other transactions but can reduce concurrency; optimistic locking allows higher concurrency by detecting conflicts at commit time (e.g., using a version/timestamp column) and retrying if needed.

Explanation

Leader-follower replication centralizes writes on the leader (simplifying consistency) while followers replicate data and can serve reads, improving read scalability and providing failover candidates.

Explanation

Allowing writes on multiple nodes (useful for multi-region setups) can lead to concurrent conflicting writes to the same data, requiring conflict resolution strategies like last-write-wins or merging.

Explanation

Opening database connections is relatively expensive; pooling maintains a set of reusable connections, reducing latency and resource usage under high request volume.

Explanation

Blue-green deployments reduce risk by keeping the old version (blue) running while the new version (green) is deployed and tested, then switching traffic, with the option to roll back quickly.

Explanation

Canary releases limit exposure to a new version, allowing teams to monitor for problems on a small scale before gradually increasing traffic, minimizing the impact of potential issues.

Explanation

Bloom filters use a bit array and hash functions to compactly represent set membership; they can say "definitely not present" with certainty, or "possibly present" (which could be a false positive), useful for quickly avoiding unnecessary lookups.

Explanation

By storing redundant copies of related data together, denormalization avoids costly joins for reads, but requires extra care to keep all copies in sync during writes.

Explanation

Stateless services can be replicated easily; a load balancer distributes incoming traffic across these replicas, enabling horizontal scaling to handle increased load.

Explanation

In event-driven systems, services react to events (e.g., "OrderPlaced") published to a broker, allowing independent services to process them asynchronously without tight coupling.

Explanation

Choosing between normalization and denormalization depends on the read/write profile of the application — OLTP systems often favor normalization, while read-heavy analytical systems may favor denormalization.

Explanation

Horizontal autoscaling (adding/removing instances) is generally preferred for stateless services due to easier load distribution, while vertical autoscaling resizes a single instance, often requiring a restart.

Explanation

When a popular cached item expires, many simultaneous requests can hit the database at once; techniques like jittered expiration times or "locking" the regeneration to one request help avoid overload.

Explanation

ACID transactions provide strong guarantees: all-or-nothing execution (Atomicity), valid state transitions (Consistency), no interference between concurrent transactions (Isolation), and persistence after commit (Durability).

Explanation

Range-based sharding preserves ordering and supports efficient range scans but can cause "hot spots" if data isn't evenly distributed; hash-based sharding distributes load more evenly but scatters related/ordered data across shards.

Explanation

DLQs isolate problematic messages (e.g., due to malformed data or persistent errors) so the main processing pipeline isn't blocked, while allowing engineers to investigate failures separately.

Explanation

For example, if a recommendation service is down, a site might still show products without personalized recommendations rather than failing the whole page — preserving core functionality.

Explanation

Push models (e.g., WebSockets, push notifications) reduce latency for real-time updates but require maintaining connections or delivery infrastructure; pull models (polling) are simpler but less timely and can waste resources on unnecessary checks.

Explanation

Feature flags decouple deployment from release, letting teams enable features for specific users/percentages or quickly disable a problematic feature without rolling back code.

Explanation

Uneven access patterns (e.g., a celebrity user's data, or a popular product) can overload a single shard; mitigations include better key design, splitting hot keys, or adding caching layers.

Explanation

Sharding by tenant provides strong data isolation and lets large tenants be moved to dedicated infrastructure, though it can complicate cross-tenant queries and analytics.

Explanation

Synchronous replication trades latency for durability guarantees, while asynchronous replication improves write latency but can lose recently committed data if the primary fails before replicas catch up.

Explanation

Offset-based pagination (LIMIT/OFFSET) becomes slow on large offsets and can show duplicates/gaps if data changes between pages; cursor-based pagination uses a stable reference point for consistent, efficient paging.

Explanation

Tools like Jaeger or Zipkin propagate a trace ID across service calls, allowing engineers to visualize the full path and timing of a request through a distributed system to pinpoint where issues occur.

Explanation

Database-per-service aligns with microservice independence and bounded contexts but requires patterns like sagas or eventual consistency for cross-service operations that a shared database would handle with simple transactions.

Explanation

Consensus algorithms like Raft/Paxos allow a majority of nodes to agree on operations despite failures, providing strong consistency guarantees at the cost of latency from cross-node coordination — often applied selectively to critical data.

Explanation

Distributed ID generation schemes (e.g., assigning ID ranges to each server, or time-based IDs like Snowflake) avoid collisions and central bottlenecks that a single shared counter or naive random generation would create at scale.

Explanation

Systems often use a hybrid: fan-out on write for most users (fast feed reads), but fan-out on read for celebrities with huge follower counts, avoiding massive write amplification when they post.

Explanation

Raft uses randomized election timeouts; when followers stop hearing from the leader, one becomes a candidate, requests votes, and becomes leader if it secures a majority, ensuring the cluster can continue operating.

Explanation

A shared, fast data store (like Redis) lets all gateway instances check and increment a common counter, ensuring rate limits are enforced globally rather than per-instance, though it introduces a dependency and potential latency/contention point.

Explanation

LSM-trees write data sequentially to immutable files (SSTables) and periodically compact/merge them; this background compaction causes data to be rewritten multiple times, increasing total disk I/O relative to the logical data written.

Explanation

Systems like Dynamo-style databases use tunable quorum parameters (N, R, W) to trade off consistency and availability — e.g., R + W > N ensures read and write quorums overlap, increasing the likelihood reads see the latest write.

Explanation

At-least-once delivery prioritizes not losing messages, accepting the possibility of duplicates during retries; consumers must therefore handle duplicates gracefully, e.g., via idempotency keys.

Explanation

Search engines build inverted indexes so that a query for a term can directly retrieve the list of matching documents (postings list), avoiding a full scan of all documents — foundational to systems like Elasticsearch.

Explanation

Because physical clocks can drift between nodes, relying on timestamps for ordering events can produce incorrect results; logical clocks (Lamport, vector clocks) capture causal relationships ("happened-before") independent of physical time.

Explanation

WALs provide durability and crash recovery by ensuring that any change is durably recorded before being considered committed, so the system can replay the log to recover state after a failure.

Explanation

Since WebSocket connections are stateful and tied to a specific server, delivering a message to a user requires knowing which instance holds their connection — often solved with a pub/sub layer (e.g., Redis Pub/Sub) so any instance can publish to the right one.

Explanation

If a client retries a payment request after a timeout (not knowing if it succeeded), including the same idempotency key lets the server recognize the retry and return the original result instead of processing the payment again.

Explanation

Offline edits and concurrent changes from multiple devices require strategies like versioning, last-write-wins with conflict copies, or more sophisticated approaches like Conflict-free Replicated Data Types (CRDTs) for real-time collaborative editing.

Explanation

Backpressure mechanisms (bounded queues, flow control protocols) prevent fast producers from overwhelming slower consumers; without them, unbounded buffering can crash systems or force data loss when buffers overflow.

Explanation

Distributed transactions (2PC) are often impractical at scale due to blocking and coordinator failure risks; sagas instead break a business process into a series of local transactions with compensating actions to maintain eventual consistency if something fails partway through.

Explanation

Before the operational complexity of sharding, teams often exhaust simpler scaling levers: read replicas for read scaling, caching layers (Redis/Memcached) to reduce database load, and query/index optimization.

Explanation

By comparing vector clock values attached to different versions of data, a system can determine if one version causally descends from another (no conflict) or if they were updated independently (concurrent, requiring conflict resolution).

Explanation

In addition to rebalancing shards, caching absorbs read load for hot keys, and techniques like key salting can split a single hot key's writes across multiple underlying partitions, reducing pressure on any one shard.

Explanation

Event sourcing offers strong auditability and time-travel capabilities, but reconstructing current state from a long event log can be slow, so systems often combine it with periodic snapshots and separate read-optimized views (CQRS).