🌍 System Design · subject

System Design Architecture Patterns and APIs Syllabus

The Architecture Patterns and APIs syllabus for System Design in full: 6 chapters and 22 topics, every one listed below, plus 60 Architecture Patterns and APIs flashcards with answers.

6Chapters
22Topics
60Flashcards

Architecture Patterns and APIs syllabus: all 6 chapters

Expand any chapter to see its topics and sub-topics.

  1. Architectural Styles

    4 topics
    • Monolithic Architecture
    • Microservices Architecture
    • Service-Oriented Architecture
    • Serverless and Function-as-a-Service
  2. API Design

    4 topics
    • REST and Richardson Maturity Model
    • GraphQL
    • gRPC and Protocol Buffers
    • API Versioning and Pagination
  3. Event-Driven Architecture

    3 topics
    • Event Sourcing
    • CQRS
    • Choreography vs Orchestration
  4. Communication Patterns

    3 topics
    • Synchronous vs Asynchronous Communication
    • Long Polling, WebSockets, SSE
    • Webhooks and Callbacks
  5. Resilience Patterns

    4 topics
    • Circuit Breaker
    • Retry with Exponential Backoff and Jitter
    • Bulkhead and Timeout Patterns
    • Graceful Degradation and Fallbacks
  6. Microservices Cross-Cutting Concerns

    4 topics
    • Service Mesh and Sidecar Pattern
    • Distributed Tracing
    • Centralized Logging and Metrics
    • Configuration and Secret Management

System Design Architecture Patterns and APIs flashcards — 60 questions with answers

  1. What is a monolithic architecture?

    A software design where all application components (UI, business logic, data access) are built and deployed as a single, unified, tightly-coupled unit running in one process.

  2. List three key advantages and three disadvantages of a monolithic architecture.

    Advantages: simple to develop/test/deploy, low operational overhead, fast in-process calls (no network latency). Disadvantages: hard to scale selectively, tight coupling slows large teams, a single bug/deploy can take down the whole app.

  3. What is microservices architecture?

    An architectural style structuring an application as a collection of small, independently deployable services, each owning a single business capability and its own data, communicating over the network (typically HTTP/REST, gRPC, or messaging).

  4. In microservices, what does 'database per service' mean and why is it used?

    Each service owns and privately manages its own database; no other service accesses it directly. It enforces loose coupling and independent scaling/deployment, at the cost of distributed data consistency (requiring patterns like Saga).

  5. Compare monolithic vs microservices on deployment, scaling, and failure isolation.

    Deployment: monolith = one unit; microservices = independent per service. Scaling: monolith = whole app; microservices = per service. Failure isolation: monolith = one failure can crash all; microservices = failures can be contained to one service.

  6. What is Service-Oriented Architecture (SOA) and how does it differ from microservices?

    SOA structures software as coarse-grained, reusable services often communicating via an Enterprise Service Bus (ESB) with shared data and enterprise-wide governance. Microservices are finer-grained, decentralized, use lightweight protocols (no heavy ESB), and favor 'smart endpoints, dumb pipes' with a database per service.

  7. What is an Enterprise Service Bus (ESB) in SOA?

    A centralized middleware component that handles message routing, transformation, protocol conversion, and orchestration between services in a Service-Oriented Architecture.

  8. What is serverless computing / Function-as-a-Service (FaaS)?

    A cloud execution model where the provider runs code in stateless, ephemeral containers triggered by events; developers deploy individual functions and are billed only for actual execution time/resources, with no server management.

  9. What is a 'cold start' in FaaS and what causes it?

    The added latency when a function is invoked and no warm container exists, so the platform must provision a container, load the runtime, and initialize code. It is caused by inactivity/scaling from zero and affects the first request after idle.

  10. Name three defining characteristics of FaaS functions.

    Stateless (no persisted local state between invocations), event-driven (triggered by events like HTTP/queue/timer), and ephemeral/auto-scaling with pay-per-use billing granular to execution.

  11. What is REST (Representational State Transfer)?

    An architectural style for networked APIs based on stateless client-server communication, uniform interface, resources identified by URIs, and manipulation via a standard set of methods (typically HTTP verbs).

  12. List the six architectural constraints of REST.

    1) Client-Server, 2) Statelessness, 3) Cacheability, 4) Uniform Interface, 5) Layered System, 6) Code on Demand (optional).

  13. What are the four levels (0-3) of the Richardson Maturity Model?

    Level 0: single URI / single HTTP method (RPC-style 'swamp of POX'). Level 1: Resources (multiple URIs, one verb). Level 2: HTTP Verbs (proper use of GET/POST/PUT/DELETE and status codes). Level 3: Hypermedia Controls (HATEOAS).

  14. What does HATEOAS mean and which Richardson level does it define?

    Hypermedia As The Engine Of Application State: responses include hypermedia links telling the client what actions/transitions are available next. It defines Level 3, the highest level, of the Richardson Maturity Model.

  15. Match HTTP methods GET, POST, PUT, DELETE, PATCH to their typical REST semantics.

    GET = retrieve resource (safe, idempotent); POST = create/non-idempotent action; PUT = create/replace resource fully (idempotent); DELETE = remove resource (idempotent); PATCH = partial update.

  16. Which HTTP methods are idempotent and which are safe?

    Safe (no state change): GET, HEAD, OPTIONS. Idempotent (same effect if repeated): GET, HEAD, OPTIONS, PUT, DELETE. POST and PATCH are generally neither safe nor guaranteed idempotent.

  17. What do HTTP status code classes 2xx, 3xx, 4xx, and 5xx represent?

    2xx = Success; 3xx = Redirection; 4xx = Client error (bad request); 5xx = Server error.

  18. What is GraphQL?

    An API query language and server-side runtime (from Facebook) where clients request exactly the data they need from a single endpoint against a strongly-typed schema, avoiding over-fetching and under-fetching.

  19. Name the three GraphQL operation types.

    Query (read data), Mutation (write/modify data), and Subscription (real-time updates, typically over WebSockets).

  20. What are over-fetching and under-fetching, and how does GraphQL address them?

    Over-fetching = endpoint returns more data than needed; under-fetching = one endpoint returns too little, forcing multiple requests. GraphQL lets clients specify exact fields in one query, so they receive precisely what they need.

Show the other 40 Architecture Patterns and APIs flashcards
  1. What is the N+1 problem in GraphQL and how is it commonly mitigated?

    When resolving a list of N items triggers 1 query for the list plus N additional queries for each item's related data. It is mitigated with batching/caching tools like DataLoader that coalesce requests within a tick.

  2. What is gRPC?

    A high-performance, open-source RPC framework by Google that uses HTTP/2 for transport and Protocol Buffers as the interface definition language and binary serialization format, supporting streaming and multiple languages.

  3. What are Protocol Buffers (protobuf)?

    A language-neutral, platform-neutral binary serialization format and IDL where message schemas are defined in .proto files and compiled into code; it is more compact and faster to parse than JSON.

  4. Name the four gRPC communication (streaming) modes.

    1) Unary (single request, single response), 2) Server streaming, 3) Client streaming, 4) Bidirectional streaming.

  5. Give three technical reasons gRPC outperforms REST/JSON for service-to-service calls.

    1) HTTP/2 multiplexing and header compression, 2) compact binary Protocol Buffers instead of text JSON, 3) built-in streaming and strongly-typed contracts with code generation.

  6. List the common API versioning strategies.

    URI/path versioning (e.g., /v2/users), query parameter (?version=2), custom header versioning, and content negotiation via the Accept header (media-type/'Accept-Version').

  7. Compare offset-based and cursor-based (keyset) pagination.

    Offset-based uses LIMIT/OFFSET (e.g., page & size) — simple but slow on deep pages and unstable when data changes. Cursor/keyset uses a pointer to the last item (e.g., WHERE id > cursor) — stable and efficient for large/real-time datasets but no random page jumps.

  8. For offset pagination, what formula converts a page number to a database offset?

    $\text{offset} = (\text{page} - 1) \times \text{pageSize}$

  9. What is Event Sourcing?

    A persistence pattern where state changes are stored as an immutable, append-only sequence of events rather than storing current state; the current state is derived by replaying the events in order.

  10. Name two key benefits and two challenges of Event Sourcing.

    Benefits: full audit trail/history and ability to reconstruct any past state (temporal queries, replay). Challenges: complexity of rebuilding/querying current state, schema/event versioning, and eventual consistency when building read models.

  11. What is a snapshot in Event Sourcing and why is it used?

    A periodically saved copy of an aggregate's current state so that rebuilding state does not require replaying the entire event history from the beginning, improving read/rehydration performance.

  12. What is CQRS (Command Query Responsibility Segregation)?

    A pattern that separates the write model (commands that change state) from the read model (queries that return data), allowing each to be optimized, scaled, and modeled independently.

  13. Why is CQRS frequently paired with Event Sourcing?

    Event Sourcing produces the stream of write-side events; CQRS uses those events to build denormalized read models (projections) optimized for queries, cleanly separating the append-only write path from optimized reads.

  14. In CQRS, what consistency model typically applies between the write and read sides?

    Eventual consistency: the read model is updated asynchronously from write-side events, so there can be a lag before reads reflect the latest writes.

  15. Compare choreography and orchestration in distributed workflows.

    Choreography: decentralized; each service reacts to events and emits its own, with no central controller (loose coupling, harder to trace). Orchestration: a central orchestrator explicitly directs and coordinates each service call (easier to monitor/control, but a central coupling point/bottleneck).

  16. In the Saga pattern, how do choreography-based and orchestration-based sagas differ?

    Choreography-based saga: services coordinate the distributed transaction by exchanging events with no central coordinator. Orchestration-based saga: a central orchestrator tells each participant which local transaction to run and issues compensating transactions on failure.

  17. 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.

  18. 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.

  19. 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.

  20. 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.

  21. 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.

  22. 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.

  23. 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.

  24. 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.

  25. 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).

  26. 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.

  27. 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).

  28. 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})$.

  29. 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.

  30. 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.

  31. 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.

  32. 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.

  33. 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).

  34. 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.

  35. 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.

  36. 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.

  37. 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.

  38. 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.

  39. 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.

  40. 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.

System Design Architecture Patterns and APIs FAQ

What is in the System Design Architecture Patterns and APIs syllabus?

System Design Architecture Patterns and APIs is split into 6 chapters: Architectural Styles, API Design, Event-Driven Architecture, Communication Patterns, Resilience Patterns and Microservices Cross-Cutting Concerns. Together they contain 22 topics.

How many chapters are in System Design Architecture Patterns and APIs?

6 chapters, containing 22 topics. The largest chapter is Architectural Styles, with 4 topics.

Are there flashcards for System Design Architecture Patterns and APIs?

Yes — a 60-card Architecture Patterns and APIs deck, printed in full in the flashcards section of this page and available in the Examius app with spaced repetition. The free plan covers one exam of your choice, including its flashcards; Examius Pro, a one-time purchase, unlocks every other exam and deck.