System Design Flashcards

Core idea

• CAP theorem says that when a network partition occurs in a distributed system, you must choose between maintaining strong consistency and maintaining availability for every request.
• This is a high-frequency interview topic because it is a classic distributed-systems concept that helps interviewers see whether you understand trade-offs during failure conditions rather than only in normal operation.
• The strongest answers do not stop at a one-line definition.
• They explain what problem the concept solves, what the operational model looks like, and how you would choose it or apply it in a realistic production setting.
• That is usually what separates a memorized answer from an interview answer that sounds experienced.

How to explain it

• A good way to explain it is to start with the simplest mental model, then expand into a concrete example.
• A good explanation starts by stressing the phrase 'in the presence of a partition'.
• If nodes cannot communicate reliably, a system may reject or delay some operations to preserve consistency, or it may continue serving requests and accept temporary divergence.
• That is the real decision space the theorem highlights.
• When you do that, the interviewer can hear your reasoning instead of just hearing terminology.
• In many interviews, that matters more than naming every possible product or edge case, because it shows you understand the underlying design rather than only the vocabulary.

Trade-offs

• You should also make the trade-offs explicit.
• The trade-offs are about business correctness versus continuity of service.
• Strong answers do not oversimplify CAP into a permanent 'pick two of three' slogan.
• They connect the theory to workload choices, such as why a payment ledger may make different decisions from a social feed.
• This is where a lot of candidates gain or lose points.
• Senior-sounding answers are rarely about saying something is 'best'.
• They are about explaining when something is appropriate, what pressure it removes, and what complexity it introduces in return.
• Interviewers usually reward that kind of balanced reasoning.

Common mistakes

• Common mistakes include ignoring partitions in the explanation, or using CAP as a vague buzzword without saying what consistency and availability mean operationally.
• Another frequent mistake is jumping too quickly to tools without first naming the requirement or access pattern that justifies the choice.
• If your explanation stays tied to workload, reliability, latency, cost, or developer ergonomics, the answer sounds much more grounded and much more useful.

Interview takeaway

• In an interview, close with a compact takeaway: The best summary is: CAP is a framework for reasoning about consistency and availability trade-offs when parts of a distributed system cannot communicate reliably.
• That kind of precise wording usually sounds much stronger than a memorized slogan.
• That final framing helps your answer feel complete and gives the interviewer a clear signal that you understand both the definition and the practical decision-making around it.

Core idea

• Eventual consistency means replicas may temporarily disagree after a write, but if no new updates occur they will converge to the same value over time.
• This is a high-frequency interview topic because it appears often because many scalable systems trade immediate global agreement for availability, latency, or regional resilience.
• The strongest answers do not stop at a one-line definition.
• They explain what problem the concept solves, what the operational model looks like, and how you would choose it or apply it in a realistic production setting.
• That is usually what separates a memorized answer from an interview answer that sounds experienced.

How to explain it

• A good way to explain it is to start with the simplest mental model, then expand into a concrete example.
• A common example is a social feed, counter, or analytics dashboard where slight staleness for a few seconds is acceptable.
• Users may not see identical results everywhere instantly, but the system can remain responsive and scalable.
• The key is that the business model tolerates that temporary divergence.
• When you do that, the interviewer can hear your reasoning instead of just hearing terminology.
• In many interviews, that matters more than naming every possible product or edge case, because it shows you understand the underlying design rather than only the vocabulary.

Trade-offs

• You should also make the trade-offs explicit.
• The trade-offs are between freshness and operational flexibility.
• Strong answers also explain where eventual consistency is not acceptable, such as payment settlement, strict inventory reservation, or security-sensitive state where stale reads can create serious correctness problems.
• This is where a lot of candidates gain or lose points.
• Senior-sounding answers are rarely about saying something is 'best'.
• They are about explaining when something is appropriate, what pressure it removes, and what complexity it introduces in return.
• Interviewers usually reward that kind of balanced reasoning.

Common mistakes

• Common mistakes include treating eventual consistency as sloppy engineering, or failing to connect the consistency choice to concrete business impact.
• Another frequent mistake is jumping too quickly to tools without first naming the requirement or access pattern that justifies the choice.
• If your explanation stays tied to workload, reliability, latency, cost, or developer ergonomics, the answer sounds much more grounded and much more useful.

Interview takeaway

• In an interview, close with a compact takeaway: The best summary is: eventual consistency is acceptable when short-lived staleness does not break product correctness and the system has a clear path to convergence.
• That workload-first framing usually makes the concept sound practical instead of purely theoretical.
• That final framing helps your answer feel complete and gives the interviewer a clear signal that you understand both the definition and the practical decision-making around it.

Core idea

• Load balancing distributes incoming traffic or work across multiple backends so no single instance becomes the only bottleneck or point of failure.
• This is a high-frequency interview topic because it is one of the most foundational scaling concepts and appears in nearly every production architecture.
• The strongest answers do not stop at a one-line definition.
• They explain what problem the concept solves, what the operational model looks like, and how you would choose it or apply it in a realistic production setting.
• That is usually what separates a memorized answer from an interview answer that sounds experienced.

How to explain it

• A good way to explain it is to start with the simplest mental model, then expand into a concrete example.
• A straightforward example is a web application behind a load balancer that routes requests across several healthy application servers.
• The same principle applies more broadly to queues, worker pools, and partition assignment: work should be spread so failures and spikes do not collapse one target.
• When you do that, the interviewer can hear your reasoning instead of just hearing terminology.
• In many interviews, that matters more than naming every possible product or edge case, because it shows you understand the underlying design rather than only the vocabulary.

Trade-offs

• You should also make the trade-offs explicit.
• The trade-offs include algorithm choice, health-check accuracy, operational simplicity, and the need for graceful draining during rollout or failure recovery.
• Strong answers focus on why load balancing exists, not only on naming round robin or least connections.
• This is where a lot of candidates gain or lose points.
• Senior-sounding answers are rarely about saying something is 'best'.
• They are about explaining when something is appropriate, what pressure it removes, and what complexity it introduces in return.
• Interviewers usually reward that kind of balanced reasoning.

Common mistakes

• Common mistakes include describing load balancing as only a front-end networking feature, or forgetting that healthy target selection and failure handling are central to its value.
• Another frequent mistake is jumping too quickly to tools without first naming the requirement or access pattern that justifies the choice.
• If your explanation stays tied to workload, reliability, latency, cost, or developer ergonomics, the answer sounds much more grounded and much more useful.

Interview takeaway

• In an interview, close with a compact takeaway: The best summary is: load balancing improves scalability and availability by spreading work across multiple healthy backends instead of one overloaded instance.
• A good interview answer often connects it directly to autoscaling and maintenance-friendly deployments.
• That final framing helps your answer feel complete and gives the interviewer a clear signal that you understand both the definition and the practical decision-making around it.

Core idea

• An index is an additional data structure that helps a database locate rows more efficiently for common queries instead of scanning the full dataset every time.
• This is a high-frequency interview topic because interviewers ask this because many real performance wins come from better data access paths before any major infrastructure redesign is needed.
• The strongest answers do not stop at a one-line definition.
• They explain what problem the concept solves, what the operational model looks like, and how you would choose it or apply it in a realistic production setting.
• That is usually what separates a memorized answer from an interview answer that sounds experienced.

How to explain it

• A good way to explain it is to start with the simplest mental model, then expand into a concrete example.
• A practical example is indexing an email column used in frequent user lookups or creating a composite index that matches a common filter-plus-sort pattern.
• Query latency can drop dramatically because the database has a faster lookup path than a full table scan.
• When you do that, the interviewer can hear your reasoning instead of just hearing terminology.
• In many interviews, that matters more than naming every possible product or edge case, because it shows you understand the underlying design rather than only the vocabulary.

Trade-offs

• You should also make the trade-offs explicit.
• The trade-offs are storage cost, write amplification, and index-maintenance complexity.
• Strong answers explain that indexing every column blindly is not smart; indexes should be chosen to support actual high-value queries and access patterns.
• This is where a lot of candidates gain or lose points.
• Senior-sounding answers are rarely about saying something is 'best'.
• They are about explaining when something is appropriate, what pressure it removes, and what complexity it introduces in return.
• Interviewers usually reward that kind of balanced reasoning.

Common mistakes

• Common mistakes include talking about indexes only as 'making the database faster' without mentioning write cost or access-pattern alignment.
• Another frequent mistake is jumping too quickly to tools without first naming the requirement or access pattern that justifies the choice.
• If your explanation stays tied to workload, reliability, latency, cost, or developer ergonomics, the answer sounds much more grounded and much more useful.

Interview takeaway

• In an interview, close with a compact takeaway: The best summary is: indexes speed up targeted reads, but they consume space and make writes more expensive, so they should follow real query patterns.
• That cost-benefit framing usually sounds much more grounded than simply praising indexes.
• That final framing helps your answer feel complete and gives the interviewer a clear signal that you understand both the definition and the practical decision-making around it.

Core idea

• Sharding means partitioning data across multiple nodes so one machine does not have to store or serve the entire dataset alone.
• This is a high-frequency interview topic because this concept is central to scaling stateful systems beyond the capacity of a single database instance.
• The strongest answers do not stop at a one-line definition.
• They explain what problem the concept solves, what the operational model looks like, and how you would choose it or apply it in a realistic production setting.
• That is usually what separates a memorized answer from an interview answer that sounds experienced.

How to explain it

• A good way to explain it is to start with the simplest mental model, then expand into a concrete example.
• A practical example is partitioning users by user ID range or hash so different subsets of user data live on different shards.
• That can improve total write capacity and storage capacity, but it also means the application or routing layer must know how to find the right shard for each request.
• When you do that, the interviewer can hear your reasoning instead of just hearing terminology.
• In many interviews, that matters more than naming every possible product or edge case, because it shows you understand the underlying design rather than only the vocabulary.

Trade-offs

• You should also make the trade-offs explicit.
• The trade-offs include higher horizontal scalability versus more routing logic, harder cross-shard queries, rebalancing complexity, and hotspot risk if the shard key distributes traffic unevenly.
• Strong answers always discuss shard-key choice rather than saying 'just shard it'.
• This is where a lot of candidates gain or lose points.
• Senior-sounding answers are rarely about saying something is 'best'.
• They are about explaining when something is appropriate, what pressure it removes, and what complexity it introduces in return.
• Interviewers usually reward that kind of balanced reasoning.

Common mistakes

• Common mistakes include ignoring hotspot risk, not mentioning cross-shard query or transaction complexity, or acting as if sharding is a free upgrade from a single database.
• Another frequent mistake is jumping too quickly to tools without first naming the requirement or access pattern that justifies the choice.
• If your explanation stays tied to workload, reliability, latency, cost, or developer ergonomics, the answer sounds much more grounded and much more useful.

Interview takeaway

• In an interview, close with a compact takeaway: The best summary is: sharding spreads load and storage, but it adds routing and operational complexity that is only worth it once simpler scaling paths are no longer enough.
• That balanced explanation usually lands well in system design interviews.
• That final framing helps your answer feel complete and gives the interviewer a clear signal that you understand both the definition and the practical decision-making around it.

Core idea

• A message queue stores work or events between producers and consumers so systems can decouple request acceptance from background processing.
• This is a high-frequency interview topic because queues are one of the most common distributed-systems building blocks because they smooth spikes and reduce tight synchronous coupling.
• The strongest answers do not stop at a one-line definition.
• They explain what problem the concept solves, what the operational model looks like, and how you would choose it or apply it in a realistic production setting.
• That is usually what separates a memorized answer from an interview answer that sounds experienced.

How to explain it

• A good way to explain it is to start with the simplest mental model, then expand into a concrete example.
• A common example is an application that accepts an image upload quickly, writes a job message to a queue, and lets background workers resize or analyze the image later.
• The user-facing request stays fast while downstream processing can happen at its own pace.
• When you do that, the interviewer can hear your reasoning instead of just hearing terminology.
• In many interviews, that matters more than naming every possible product or edge case, because it shows you understand the underlying design rather than only the vocabulary.

Trade-offs

• You should also make the trade-offs explicit.
• The trade-offs include extra operational components, eventual rather than immediate completion, and the need to think about retries, duplicates, dead-letter handling, and idempotent consumers.
• Strong answers mention both the decoupling benefit and the new failure modes.
• This is where a lot of candidates gain or lose points.
• Senior-sounding answers are rarely about saying something is 'best'.
• They are about explaining when something is appropriate, what pressure it removes, and what complexity it introduces in return.
• Interviewers usually reward that kind of balanced reasoning.

Common mistakes

• Common mistakes include pretending queues make processing magically reliable without discussing duplicate delivery, backlogs, or worker failure behavior.
• Another frequent mistake is jumping too quickly to tools without first naming the requirement or access pattern that justifies the choice.
• If your explanation stays tied to workload, reliability, latency, cost, or developer ergonomics, the answer sounds much more grounded and much more useful.

Interview takeaway

• In an interview, close with a compact takeaway: The best summary is: message queues improve resilience and scalability by buffering work, but they require careful retry, ordering, and observability design.
• That systems-thinking angle usually sounds much stronger than simply saying queues are 'for async'.
• That final framing helps your answer feel complete and gives the interviewer a clear signal that you understand both the definition and the practical decision-making around it.

Core idea

• Idempotency means that performing the same logical operation multiple times has the same intended business effect as performing it once.
• This is a high-frequency interview topic because retries, duplicate deliveries, and uncertain network outcomes are normal in distributed systems, so safe repetition is essential.
• The strongest answers do not stop at a one-line definition.
• They explain what problem the concept solves, what the operational model looks like, and how you would choose it or apply it in a realistic production setting.
• That is usually what separates a memorized answer from an interview answer that sounds experienced.

How to explain it

• A good way to explain it is to start with the simplest mental model, then expand into a concrete example.
• A practical example is a payment API using an idempotency key.
• If a client times out and retries the same payment request, the service can return the original result instead of creating a second charge.
• The same idea applies to message processing, order creation, and many event-driven flows.
• When you do that, the interviewer can hear your reasoning instead of just hearing terminology.
• In many interviews, that matters more than naming every possible product or edge case, because it shows you understand the underlying design rather than only the vocabulary.

Trade-offs

• You should also make the trade-offs explicit.
• The trade-offs include extra design effort around unique identifiers, deduplication state, and business semantics, but the payoff is huge reliability under retry-heavy real-world conditions.
• Strong answers distinguish business effect from incidental side effects such as repeated logs or metrics.
• This is where a lot of candidates gain or lose points.
• Senior-sounding answers are rarely about saying something is 'best'.
• They are about explaining when something is appropriate, what pressure it removes, and what complexity it introduces in return.
• Interviewers usually reward that kind of balanced reasoning.

Common mistakes

• Common mistakes include thinking idempotency only matters for HTTP methods on paper, or not connecting it to retries and duplicate delivery in real systems.
• Another frequent mistake is jumping too quickly to tools without first naming the requirement or access pattern that justifies the choice.
• If your explanation stays tied to workload, reliability, latency, cost, or developer ergonomics, the answer sounds much more grounded and much more useful.

Interview takeaway

• In an interview, close with a compact takeaway: The best summary is: idempotency allows systems to retry safely without repeating the underlying business action.
• That one sentence captures why the concept appears so often in production architecture discussions.
• That final framing helps your answer feel complete and gives the interviewer a clear signal that you understand both the definition and the practical decision-making around it.

Core idea

• Caching stores reusable data or results in a faster layer so later requests can be served with lower latency and less backend load.
• This is a high-frequency interview topic because caching is one of the first performance tools people reach for, so interviewers want to know whether you understand its hidden costs too.
• The strongest answers do not stop at a one-line definition.
• They explain what problem the concept solves, what the operational model looks like, and how you would choose it or apply it in a realistic production setting.
• That is usually what separates a memorized answer from an interview answer that sounds experienced.

How to explain it

• A good way to explain it is to start with the simplest mental model, then expand into a concrete example.
• A typical example is storing hot product pages, user profiles, or expensive query results in Redis or a CDN.
• Reads become much faster, and the database receives fewer repeated requests.
• This can dramatically improve both latency and cost at scale.
• When you do that, the interviewer can hear your reasoning instead of just hearing terminology.
• In many interviews, that matters more than naming every possible product or edge case, because it shows you understand the underlying design rather than only the vocabulary.

Trade-offs

• You should also make the trade-offs explicit.
• The trade-offs include staleness, invalidation difficulty, stampedes on misses, hot keys, and the temptation to cache data whose correctness requirements are too strict.
• Strong answers always say what can be stale, how invalidation works, and what happens when the cache is empty or unavailable.
• This is where a lot of candidates gain or lose points.
• Senior-sounding answers are rarely about saying something is 'best'.
• They are about explaining when something is appropriate, what pressure it removes, and what complexity it introduces in return.
• Interviewers usually reward that kind of balanced reasoning.

Common mistakes

• Common mistakes include talking about cache only as a speed boost, or ignoring freshness rules and the complexity of invalidation.
• Another frequent mistake is jumping too quickly to tools without first naming the requirement or access pattern that justifies the choice.
• If your explanation stays tied to workload, reliability, latency, cost, or developer ergonomics, the answer sounds much more grounded and much more useful.

Interview takeaway

• In an interview, close with a compact takeaway: The best summary is: a cache can make systems much faster, but it also creates a new consistency and failure-management problem that must be designed intentionally.
• That trade-off-focused explanation usually sounds far more mature than 'just add Redis'.
• That final framing helps your answer feel complete and gives the interviewer a clear signal that you understand both the definition and the practical decision-making around it.

Core idea

• Observability is the ability to understand a system's internal behavior from its outputs, usually through metrics, logs, traces, and contextual signals that support investigation.
• This is a high-frequency interview topic because it matters because operating a distributed system means diagnosing failures you did not predict ahead of time.
• The strongest answers do not stop at a one-line definition.
• They explain what problem the concept solves, what the operational model looks like, and how you would choose it or apply it in a realistic production setting.
• That is usually what separates a memorized answer from an interview answer that sounds experienced.

How to explain it

• A good way to explain it is to start with the simplest mental model, then expand into a concrete example.
• A practical example is a checkout issue that affects only one region, payment method, and recent deployment version.
• Basic monitoring may tell you latency is high, but observability should help you trace the exact request path, inspect structured logs, and correlate the failure to a specific dependency or code change.
• When you do that, the interviewer can hear your reasoning instead of just hearing terminology.
• In many interviews, that matters more than naming every possible product or edge case, because it shows you understand the underlying design rather than only the vocabulary.

Trade-offs

• You should also make the trade-offs explicit.
• The trade-offs include instrumentation effort, signal volume, storage cost, and the need to design for debuggability up front.
• Strong answers distinguish monitoring known conditions from observability for unknown conditions.
• Both matter, but they are not the same thing.
• This is where a lot of candidates gain or lose points.
• Senior-sounding answers are rarely about saying something is 'best'.
• They are about explaining when something is appropriate, what pressure it removes, and what complexity it introduces in return.
• Interviewers usually reward that kind of balanced reasoning.

Common mistakes

• Common mistakes include equating observability with a dashboard of CPU graphs, or not mentioning logs, traces, correlation IDs, or investigation workflows.
• Another frequent mistake is jumping too quickly to tools without first naming the requirement or access pattern that justifies the choice.
• If your explanation stays tied to workload, reliability, latency, cost, or developer ergonomics, the answer sounds much more grounded and much more useful.

Interview takeaway

• In an interview, close with a compact takeaway: The best summary is: monitoring tells you that something is wrong, while observability helps you understand why it is wrong.
• That difference is often exactly what the interviewer wants to hear.
• That final framing helps your answer feel complete and gives the interviewer a clear signal that you understand both the definition and the practical decision-making around it.

Core idea

• Backpressure is the set of mechanisms a system uses to resist overload when incoming work arrives faster than downstream components can process it safely.
• This is a high-frequency interview topic because this topic shows whether you understand how healthy systems avoid meltdown under spikes instead of only how they perform under ideal load.
• The strongest answers do not stop at a one-line definition.
• They explain what problem the concept solves, what the operational model looks like, and how you would choose it or apply it in a realistic production setting.
• That is usually what separates a memorized answer from an interview answer that sounds experienced.

How to explain it

• A good way to explain it is to start with the simplest mental model, then expand into a concrete example.
• A practical example is a bounded worker queue that starts rejecting, delaying, or throttling new work once it reaches safe capacity, rather than growing without limit and causing memory, timeout, and retry cascades.
• Request-path systems may use concurrency limits, rate limits, circuit breakers, or 429/503 responses for the same reason.
• When you do that, the interviewer can hear your reasoning instead of just hearing terminology.
• In many interviews, that matters more than naming every possible product or edge case, because it shows you understand the underlying design rather than only the vocabulary.

Trade-offs

• You should also make the trade-offs explicit.
• The trade-offs include throughput versus stability and user convenience versus controlled shedding.
• Strong answers mention that blind retries can worsen overload and that backpressure usually works together with idempotency, admission control, and graceful degradation.
• This is where a lot of candidates gain or lose points.
• Senior-sounding answers are rarely about saying something is 'best'.
• They are about explaining when something is appropriate, what pressure it removes, and what complexity it introduces in return.
• Interviewers usually reward that kind of balanced reasoning.

Common mistakes

• Common mistakes include saying systems should always accept more traffic if possible, or talking about buffering without naming the limits that prevent runaway growth.
• Another frequent mistake is jumping too quickly to tools without first naming the requirement or access pattern that justifies the choice.
• If your explanation stays tied to workload, reliability, latency, cost, or developer ergonomics, the answer sounds much more grounded and much more useful.

Interview takeaway

• In an interview, close with a compact takeaway: The best summary is: backpressure protects systems by slowing, limiting, buffering, or shedding work before overload turns into a cascading failure.
• That resilience-focused explanation usually makes the concept sound concrete and production-relevant.
• That final framing helps your answer feel complete and gives the interviewer a clear signal that you understand both the definition and the practical decision-making around it.