🌍 System Design · flashcards

System Design Architecture Patterns and APIs Flashcards

60 question-and-answer cards covering Architecture Patterns and APIs as it is examined in System Design. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.

60Cards in deck
24Free preview
22Syllabus topics
~237Chars per answer
FreePrice

24 sample cards from the Architecture Patterns and APIs deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

  1. What is a compensating transaction in a Saga?

    An action that semantically undoes the effect of a previously completed local transaction when a later step in the distributed saga fails, restoring consistency without traditional ACID rollback.

  2. Compare synchronous and asynchronous communication between services.

    Synchronous: caller sends a request and blocks/waits for the response (e.g., HTTP/gRPC) — simple but creates temporal coupling. Asynchronous: caller sends a message and continues without waiting (e.g., message queues/events) — decoupled and resilient, but adds complexity and eventual consistency.

  3. What is temporal coupling and which communication style reduces it?

    Temporal coupling is when both services must be available at the same time for an interaction to succeed (typical of synchronous calls). Asynchronous, message/queue-based communication reduces it by buffering messages so the receiver need not be up simultaneously.

  4. How does traditional HTTP polling differ from long polling?

    Regular polling: client repeatedly sends requests at fixed intervals; the server responds immediately even if there is no new data (wasteful). Long polling: the server holds the request open until data is available (or timeout), then responds, and the client immediately reopens a new request.

  5. Compare WebSockets, Server-Sent Events (SSE), and long polling on directionality and transport.

    WebSockets: full-duplex bidirectional over a single persistent TCP connection (ws://). SSE: unidirectional server-to-client over a persistent HTTP connection, auto-reconnect, text-only. Long polling: emulated push using repeated held HTTP requests, higher overhead.

  6. When would you choose SSE over WebSockets?

    When you only need one-way server-to-client streaming (e.g., live feeds, notifications, stock tickers), want to reuse plain HTTP with automatic reconnection and simpler infrastructure, and do not need client-to-server messaging over the same channel.

  7. What is a webhook?

    A user-defined HTTP callback where a server proactively sends an HTTP POST to a pre-registered client URL when a specific event occurs, enabling event-driven 'push' integration instead of the client polling for changes.

  8. Contrast webhooks with polling and explain how webhook security is typically ensured.

    Polling has the client repeatedly ask for updates (wasteful, delayed); webhooks push data only when events occur (efficient, near real-time). Security is commonly ensured by verifying an HMAC signature in a header computed over the payload with a shared secret.

  9. What is the Circuit Breaker pattern and what are its three states?

    A resilience pattern that stops calling a failing dependency to prevent cascading failures. States: Closed (calls flow, failures counted), Open (calls fail fast immediately without invoking the dependency), and Half-Open (a limited number of trial calls test recovery; success closes it, failure reopens it).

  10. What triggers a Circuit Breaker to move from Closed to Open?

    When the failure rate or count of failed calls crosses a configured threshold within a monitoring window, the breaker trips to Open and begins failing fast.

  11. What is retry with exponential backoff, and why add jitter?

    Retrying a failed request while exponentially increasing the wait between attempts (e.g., 1s, 2s, 4s, 8s) to avoid overwhelming a recovering service. Jitter adds randomness to the delay so many clients don't retry in sync (avoiding the 'thundering herd'/retry storm).

  12. Write the formula for the retry delay in exponential backoff (attempt $n$, base delay $b$).

    $$\text{delay}(n) = b \times 2^{\,n}$$ often capped at a maximum: $\text{delay}(n) = \min(\text{cap},\, b \times 2^{\,n})$.

  13. Give the formula for 'full jitter' exponential backoff.

    $$\text{delay} = \text{random}\!\left(0,\ \min(\text{cap},\ b \times 2^{\,n})\right)$$ where the actual wait is uniformly sampled between 0 and the computed backoff bound.

  14. What is the Bulkhead pattern?

    A resilience pattern that isolates resources (e.g., separate thread pools, connection pools, or service instances) per dependency or client so that a failure or resource exhaustion in one partition cannot sink the entire system — named after watertight ship compartments.

  15. What is the Timeout pattern and why is it essential in distributed systems?

    Setting a maximum time to wait for a response before aborting a call. It is essential because it prevents threads/resources from blocking indefinitely on a slow or hung dependency, freeing resources and enabling fast failure and fallbacks.

  16. How do the Timeout, Retry, and Circuit Breaker patterns typically work together?

    Timeout bounds each call so it fails fast; Retry (with backoff/jitter) re-attempts transient failures; Circuit Breaker counts failures and opens to stop retrying a persistently failing dependency, preventing cascading overload.

  17. What is graceful degradation?

    Designing a system so that when a component or dependency fails, the application continues operating with reduced functionality rather than failing completely (e.g., disabling recommendations but still serving the catalog).

  18. What is a fallback in resilience engineering? Give an example.

    An alternative response or path used when the primary operation fails or times out — e.g., returning cached/stale data, a default value, or a queued action instead of an error, so the user still gets a usable result.

  19. Distinguish graceful degradation from a fallback.

    A fallback is a specific alternative action for one failed operation (e.g., serve cached data). Graceful degradation is the broader system-level strategy of maintaining partial/core functionality under failure, often implemented using multiple fallbacks.

  20. What is the 'thundering herd' problem and which patterns mitigate it?

    When many clients simultaneously retry or hit a resource (e.g., after an outage or cache expiry), overwhelming the recovering service. Mitigations include jittered exponential backoff, circuit breakers, request coalescing, and rate limiting.

  21. Why is statelessness important for horizontally scaling REST and FaaS services?

    Because no client session state is stored on a specific instance, any request can be routed to any instance; this lets you add/remove instances freely behind a load balancer and enables auto-scaling and fault tolerance.

  22. What HTTP status code is conventionally returned when a Circuit Breaker is open or a service is overloaded, and what does it signal?

    503 Service Unavailable (often with a Retry-After header), signaling the service is temporarily unable to handle the request and the client should retry later.

  23. In event-driven microservices, what is the difference between an event and a command?

    An event is an immutable statement that something has already happened (past tense, e.g., 'OrderPlaced'), broadcast to any interested subscribers. A command is a directive to a specific handler to perform an action (imperative, e.g., 'PlaceOrder') and expects it to be executed.

  24. What is idempotency and why is it critical for retries and message processing?

    An operation is idempotent if performing it multiple times yields the same result as performing it once. It is critical because retries and at-least-once message delivery can cause duplicates; idempotent handlers (often via idempotency keys) prevent double-processing side effects.

What this deck covers

The Architecture Patterns and APIs deck follows the System Design Architecture Patterns and APIs syllabus — 6 chapters and 22 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 10.0 cards per chapter.

Answers are written to be recallable, not just readable — averaging about 237 characters, which is long enough to carry the reasoning and short enough to say out loud.

A deck like this earns its keep on the second and third pass. Read the syllabus first so you know the shape of the subject, then use the cards to find the specific facts that have not stuck.

Architecture Patterns and APIs flashcards FAQ

How many Architecture Patterns and APIs flashcards are in this System Design deck?

60 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.

Are these System Design flashcards free?

Yes. The preview here is free to read with no signup, and the full 60-card deck is free inside the Examius app.

What do the Architecture Patterns and APIs cards cover?

They follow the System Design Architecture Patterns and APIs syllabus — 6 chapters and 22 topics — so the questions track what is actually examinable.

How should I use these flashcards?

Read the syllabus first so you know the shape of the subject, then drill the deck. Examius schedules each card with spaced repetition, so cards you keep missing come back sooner and ones you know drift further apart.